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ABSTRACT 


The  multi-backended  database  system  (MBDS)  is  a  database  system  designed 
for  very  large  databases.  MBDS  is  intended  to  provide  consistent  performance 
with  increased  capacity  (or  improved  performance  at  a  sustained  capacity)  by  dis¬ 
tributing  the  work  of  the  system  among  several  micro-computers  connected  to  a 
common  communication  network.  One  of  the  issues  central  to  the  MBDS  design 
is  the  portability  of  the  system's  software.  This  thesis  provides  a  general  discus¬ 
sion  of  the  issues  involved  in  software  portability,  and  then  presents  a  case  study 
of  the  MBDS  software  system. 
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I.  AN  INTRODUCTION 


A.  THE  BACKGROUND 

It  should  come  as  no  surprise  to  anyone  involved  in  computer  science  to  say 
that  the  essence  of  the  entire  field  is  changing.  This  is  probably  true  for  those 
persons  involved  in  software  development.  The  trend  of  rapidly  decreasing 
hardware  costs  remains  steady,  and  shows  no  signs  of  changing  course  in  the  near 
future.  Software  costs  therefore  represent  an  ever  increasing  percentage  of  total 
system  costs. 

As  the  level  of  technology  increases,  and  the  relative  costs  of  hardware  con¬ 
tinues  to  decrease,  the  expense  of  upgrading  to  larger,  more  powerful  computing 
systems  becomes  less  restrictive.  Except  for  the  ever  present  (and  increasing)  cost 
of  new  software,  the  obvious  requirement  then  is  for  the  software  to  be  easily 
ported  from  one  system  to  another.  Assuming  an  environment  of  truly  portable 
software,  users  would  find  themselves  in  a  situation  where  the  only  real  costs  to  be 
considered  when  evaluating  a  change  to  a  new  system  would  be  the  cost  of  the 
hardware  alone. 

There  are  some  obvious  benefits  to  this  situation.  When  the  need  arises  for  a 
greater  capacity  or  an  increased  throughput  to  meet  the  new  requirements,  the 
upgrade  becomes  an  easier  task.  Additionally,  more  powerful  software  can  be 
purchased  at  the  outset,  when  the  original  computing  systems  are  acquired.  Since 
the  useful  life  of  a  software  item  would  no  longer  end  when  its  underlying 
hardware  is  replaced,  higher  initial  expenses  for  software  could  be  justified. 
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Cost  is  not  the  only  factor  in  support  of  software  portability.  It  is  often  desir¬ 
able  to  provide  a  uniform,  consistent  environment  across  several  different  comput¬ 
ing  systems.  The  days  of  the  single  mainframe  which  supports  all  of  the  com¬ 
puter  needs  in  an  organization  are  fading.  Many  organizations  now  have  several 
different  computing  systems  (usually  minis  or  micros).  They  may  be  made  by 
different  manufacturers,  run  by  different  operating  systems,  used  for  different 
tasks,  and  are  networked  together  frequently  to  provide  a  very  powerful  comput¬ 
ing  environment  where  resources  may  be  shared. 

It  is  also  common  to  see  that  the  same  operating  system  is  running  on  several 
different  computers  (e.g.,  UNIX,  which  runs  on  VAX  main  frames.  ISI  32-bit 
micro-computers.  IBM  16-bit  micro-computers,  et.  ah).  Conversely,  hardware 
manufacturers  often  provide  a  choice  of  operating  systems  which  will  run  on  the 
same  hardware:  and  applications  developers  will  provide  versions  of  their  software 
which  run  under  different  operating  systems,  and  allow  exchange  of  data  between 
them  without  modification.  In  such  an  environment  it  is  not  unreasonable  for  a 
user  to  desire  programs  which  can  be  moved  between  several  computing  systems. 

B.  AN  OVERVIEW 

Portability  is  essentially  the  ability  of  software  to  migrate  among  different 
hardware  configurations  and  operating  systems  with  little,  or  no.  modification. 
This  thesis  will  provide  a  discussion  of  techniques  which  can  be  used  to  achieve  a 
higher  degree  of  portability  for  software  in  general,  and  database  management 
software  in  particular. 

The  need  for  portable  software  is  evident  through  all  areas  of  computer  sci¬ 
ence.  database  management  systems  (DBMS)  present  a  particularly  strong  need 
for  it.  Conceptually.  DBMS  software  can  be  thought  of  as  a  specialized  operating 


system.  Like  an  operating  system.  DBMS  accepts  commands  from  a  command 
language  (data  language),  and  uses  the  commands  to  manage  and  manipulate  files 
(data).  System  users  utilize  both  DBMS  and  the  operating  system  as  support 
tools.  Like  operating  systems,  the  DBMS  software  tends  to  be  complex  and 
expensive,  often  taking  many  years  to  develop. 

The  DBMS  software  however  presents  something  of  a  paradox  in  that  the 
more  powerful  DBMS  is.  the  quicker  it  exceeds  its  usefulness.  This  happens  not 
because  DBMS  ceases  to  be  adequate,  but  because  the  hardware  on  which  the  sys¬ 
tem  is  running  can  no  longer  handle  all  of  the  work  which  the  DBMS  software  is 
trying  to  accomplish. 

The  better  DBMS  is.  the  more  users  there  are.  Unfortunately,  the  increasing 
strain  which  a  growing  database  places  on  a  computing  system  is  not  linear. 
Response  times  increase  drastically,  and  soon,  running  nondatabase  operations 
concurrently  with  DBMS  becomes  infeasible.  Eventually,  even  running  DBMS  as 
a  standalone  system  becomes  uneconomical. 

One  obvious  answer  to  this  dilemma  is  to  go  to  larger,  stand  alone,  comput¬ 
ing  systems  for  handling  database  functions.  There  is  no  reason  to  believe,  how¬ 
ever.  that  this  is  anything  but  a  short-term  solution.  Databases  will  almost  always 
continue  to  grow,  so  the  emphasis  is  once  again  on  the  need  for  the  portable 
DBMS  software  which  can  be  moved  from  one  system  to  another  system. 

Researchers  in  the  area  of  database  management  are  finding  new  ways  to 
improve  the  efficiency  of  the  DBMS  software,  and  reduce  the  strain  that  the 
DBMS  software  imposes  upon  the  mainframes  called  hosts.  One  current  project, 
is  the  multi-backended  database  system  (MBDS).  MBDS  is  aiming  at  meeting 
both  of  these  goals  by  placing  the  DBMS  software  on  independent  micro¬ 
computers  known  as  the  backends  which  are  connected  to  each  other,  and  to  their 


host  via  a  communications  link.  Since  most  processing  with  MBDS  is  on  indepen¬ 
dent  computers,  no  real  strain  is  placed  upon  the  host  computer.  MBDS  provides 
for  increased  capacity  without  decreased  performance  (or  increased  performance 
at  the  same  capacity),  by  the  addition  of  micro-computers. 

MBDS  places  no  restraint  on  either  the  host  computer  type,  or  the  micro¬ 
computer  backend.  There  is  also  no  restriction  on  the  method  used  to  establish 
the  communications  link.  In  order  to  provide  this  freedom,  and  since  the  system 
is  designed  with  the  intention  of  migrating  to  various  hardware  configurations 
(possibly  at  frequent  intervals),  the  MBDS  software  must  be  easily  portable. 

Due  to  the  great  desire  for  portability  in  database  software  and  the  addi¬ 
tional  efforts  by  the  designers  of  MBDS  to  achieve  it.  MBDS  represents  an  excel¬ 
lent  example  of  methods  which  can  be  used  to  provide  software  portability.  The 
methods  used  are  applicable  to  the  software  portability  in  general,  and  to  the  por¬ 
tability  of  the  DBMS  software  in  particular.  As  such,  one  implementation  of  the 
MBDS  design  is  used  for  discussion  throughout  this  thesis.  A  complete  descrip¬ 
tion  of  MBDS  design  can  be  found  in  Reference  1  and  Reference  2. 

C.  THE  ORGANIZATION  OF  THESIS 

Chapter  II  presents  a  paradigm  for  a  software  system,  and  describes  the  parts 
of  a  computing  environment.  A  discussion  is  presented  on  how  the  various  com¬ 
ponents  of  a  software  system  (presented  in  the  paradigm)  interact  with  each  part 
of  the  computing  environment.  Also  discussed  are  the  effects  that  changing  each 
parT  of  the  computing  environment  have  on  the  components  of  a  software  system. 

In  chapter  III  wre  describe  the  components  of  the  multi-backended  database 
system  (MBDS)  according  to  the  framework  of  our  paradigm.  The  porting  of 
MBDS  from  one  computing  system  to  another  is  discussed,  and  the  effects  of  the 


porting  on  the  MBDlr  software  components  are  presented.  The  actual 
modifications  which  are  necessary  to  port  the  MBDS  software  are  presented  in 
chapter  IV. 


II.  THE  SOFTWARE-SYSTEM  PORTABILITY 


I  - 

l 

1 

t 

Before  progressing  with  any  discussion  of  how  to  achieve  the  portability  of  a 
software  system  we  must  have  some  concept  of  what  portability  is,  and  what 

> 

comprises  a  software  system.  Only  then  can  we  correctly  determine  what  the 
issues  are  and  their  impact  upon  the  portability,  and  how  these  issues  should  be 
approached  and  analyzed.  Probably  no  two  definitions  of  the  software  portability 

* 

!  exactly  coincide,  depending  on  the  background  of  the  person  providing  the 

1 

i  definition,  and  the  scope  of  the  problem  at  hand.  However,  there  are  some  gen- 

|  eral  points  that  all  of  the  different  definitions  are  likely  to  agree  on. 

The  software-system  portability  is  the  ability  of  a  software  system  to  migrate 
from  one  to  another  computing  environment  (i.e.,  hardware  and  operating  system 

|  combinations)  with  little,  or  no.  changes  of  the  software  system  required.  Changes 

which  are  required  should  be  consistent  and  of  a  regular  nature,  so  that  these 
changes  can  be  accommodated,  if  possible,  by  some  mechanical  means. 

|  Given  this  definition,  we  now  must  focus  on  what  constitutes  a  software  sys¬ 

tem.  Software  systems  can  be  designed  for  many  different  purposes.  In  order  to 
carry  out  their  intended  job  they  usually  have  various  parts  (some  times  hundreds 
of  them),  each  of  which  satisfies  some  specific  requirement.  There  are  usually  sec¬ 
tions  for  carrying  out  normal  processing  and  for  creating  and  manipulating  data 
structures.  Most  software  systems  also  require  access  to  device  drivers  to  enable 
terminal  I/O  or  communication  with  other  software  systems,  either  within  the 
same  computer  or  over  some  distributed  network. 


Regardless  of  the  software  system  in  question,  its  portability  is  not  deter¬ 
mined  by  what  the  software  system  is  intended  to  do.  or  how  many  parts  it  has. 
but  by  how  the  software  system  was  structured.  Therefore,  the  issues  affecting 
the  portability  are  general  to  all  types  of  software  systems,  since  all  of  the 
software  systems  have  some  structure.  The  concepts  to  be  discussed  do  not  vary, 
nor  does  its  basis,  on  whether  the  software  system  is  a  database  system,  operating 
system,  a  compiler,  or  any  other  type  of  systems.  In  the  rest  of  this  chapter  we 
examine  what  those  issues  are.  A  case  study  on  the  portability  is  presented  in  the 
next  chapter,  using  the  multi-backended  database  system  (MBDS)  as  an  example. 

A.  A  PARADIGM  FOR  A  SOFTWARE  SYSTEM 

In  this  section  we  present  a  paradigm  for  the  structure  and  form  of  a  software 
system.  This  paradigm  is  based  on  the  two  types  of  components  that  are  used  to 
construct  a  software  system.  They  are  system  source  code  and  operating  system 
commands.  There  are  three  types  of  system  source  code,  namely, 

•  machine  code, 

•  assembler  code,  and 

•  high-level  code. 

Operating  system  commands  take  the  form  of 

•  basic  commands. 

•  command  files,  and 

•  utilities. 

First,  we  investigate  the  system-source-code  component.  For  each  type  of 
code  in  the  system-source-code  component,  our  paradigm  provides  up  to  three 
types  of  processing: 


•  basic  processing. 

•  runtime-environment  processing,  and 

•  translator-environment  processing. 

In  the  following  discussion,  we  investigate  the  form  that  each  of  the  three  kinds  of 
processing  takes  for  each  of  the  three  types  of  the  system  source  code 

The  machine  code  is  just  binary  code  written  for  the  particular  machine  the 
program  runs  on.  The  basic  processing  functions  for  machine  code  include  opera¬ 
tions  such  as  add.  subtract  and  store.  There  is  no  runtime-environment  process¬ 
ing.  or  translator-environment  processing  available  with  the  machine  code. 

The  assembler  code,  while  it  is  at  a  higher  level  than  the  machine  code,  usu¬ 
ally  results  in  only  a  few  machine  instructions  per  line  of  the  source  code.  The 
capabilities  at  the  basic  processing  It  he  assembler  code  parallel  those  of 

the  machine  code.  However,  the  asseiuo^  code  allows  logical  names  and  per¬ 
forms  the  automatic  calculation  of  machine  addresses.  The  runtime-environment 
processing  for  the  assembler  code  involves  calls  to  the  operating  system  for  per¬ 
forming  such  functions  as  reading  characters  from  files,  or  obtaining  the  current 
date  and  time.  Assemblers  generally  do  not  provide  any  translator-environment 
processing  capabilities. 

The  high-level  code  refers  to  compiler  languages  such  as  (  or  Pascal.  For  the 
high-level  code,  basic  processing  capabilities  include  mathematical  operations,  log¬ 
ical  comparisons,  and  assignment  of  values  to  logical  variables.  They  also  include 
all  those  statements  in  the  language  which  we  call  the  runtime-environment  pro¬ 
cessing  or  translator-environment  processing.  The  runtime-environment¬ 
processing  capabilities  include  operations  such  as  reading  and  writing  files, 
dynamically  allocating  the  memory  and  providing  calls  for  communicating  with 
other  software  systems.  The  high-level  calls  to  be  carried  out  by  the  operating 


system  constitute  the  runtime-environment  processing.  The  translator- 
environment  processing  is  any  function  that  is  carried  out  by  library  routines 
which  are  provided  as  a  part  of  the  translator  and  incorporated  into  the  software 
system  at  the  link  time.  Included  in  the  translator-environment  processing  are 
operations  such  as  floating-point  arithmetic,  computation  of  trigonometric  values 
and  manipulation  of  character  strings. 

Now  let  us  consider  the  operating-system-command  component  of  a  software 
system.  The  basic  operating  system  commands  include  those  for  compiling, 
assembling  and  linking  the  source  code  of  all  types  (i.e.,  machine,  assembler  and 
high-level);  and  for  deleting,  copying  and  renaming  files.  Command  files  are  lists 
of  basic  processing  commands  which  automatically  execute,  in  sequence,  or 
according  to  some  programming  logic  dictated  by  the  operating  system.  The  util¬ 
ities  of  the  operating  system  are  prewritten  command  files  which  are  included  as  a 
part  of  the  operating  system.  Utilities  may  perform  logically  complex  operations 
and  are  designed  to  aid  in  the  implementation  and  management  of  large  software 
systems.  Included  in  these  are  system  libraries  and  implementation  aids  such  as 
version  control  systems  and  file-creation  utilities. 

We  should  take  the  time  here  to  note  an  important  point.  Wrhile  all  of  the 
code  is  eventually  translated  into  the  machine  code  and  runtime  libraries  may 
make  calls  to  the  operating  system,  neither  of  these  directly  affects  the  portability 
of  the  software.  The  issues  are  what  types  of  the  system  source  code  that  the 
software  system  is  written  in.  and  which  types  of  processing  are  performed.  These 
are  what  determine  the  portability  of  the  software  system. 


B.  TYPES  OF  PORTING 


We  have  defined  the  porting  as  the  movement  of  a  software  system  form  one 
computing  environment  to  another.  There  are  three  parts  which  make  up  a  com¬ 
puting  environment. 

•  the  hardware. 

•  the  operating  system,  and 

•  the  translator  (in  the  case  of  the  assembled  or  high-level  code). 

A  software  system  may  be  ported  by  changing  any  of  the  three  parts  of  the  com¬ 
puting  environment.  Each  of  these  changes  has  a  different  impact  on  the  software 
system  being  ported.  There  may  of  course  be  changes  to  several  items  at  once. 
For  example,  a  change  of  operating  systems  usually  requires  a  change  of  transla¬ 
tors  as  well,  since  most  compilers  are  written  to  run  on  a  particular  operating  sys¬ 
tem.  We  now  use  the  paradigm  we  have  created  to  examine  the  effects  that  each 
type  of  porting  has  on  a  software  system. 

1.  A  Change  of  the  Hardware 

For  any  software  system,  the  most  profound  effects  of  changing  hardware 
are  in  the  system-source-code  component.  Any  portions  of  a  program  written  in 
the  machine  code  obviously  are  affected  by  a  change  of  the  hardware.  Unless  the 
new  hardware  used  allows  for  the  emulation  of  the  original  machine,  all  machine 
code  must  be  rewritten.  The  assembler  code  usually  must  be  redone  as  well 
because  it  is  so  closely  tied  to  the  structure  of  the  underlying  machine. 

The  high-level  code  usually  does  not  have  to  be  redone  due  solely  to  a 
change  of  hardware  as  long  as  that  new  hardware  supports  a  compatible  version 
of  the  original  operating  system  and  that  a  compiler  is  available  for  the  high-level 
language  in  question.  However,  this  is  not  always  the  case.  If  the  high-level 


language  is  not  widely  used  (e.g..  BLISS),  then  there  might  not  be  a  compiler 
available  with  a  code  generator  for  the  new  machine. 

Operating-system  commands  are  not  affected  by  a  change  of  the 
hardware  alone,  since  two  versions  of  an  operating  system  running  on  two 
different  sets  of  hardware  can  usually  be  expected  to  provide  the  same  functions. 
Thus,  in  the  case  of  a  hardware-only  change,  the  type  of  code  used  (machine, 
assembler,  or  high-level)  is  what  determines  the  changes  to  be  made  to  the  system 
source  code.  There  is  usually  no  affect  on  the  operating-system-command  com¬ 
ponent  of  the  software  system. 

2.  A  Change  of  Translators 

Changing  the  translator  only  has  an  effect  on  the  assembled  and  high- 
level  code  in  the  system-source-code  component  (the  machine  code  does  not  use  a 
translator).  The  kinds  of  processing  which  the  code  (assembled  or  high-level)  per¬ 
forms  affect  the  changes  which  have  to  be  made.  Necessary  changes  to  the  code 
which  accomplishes  the  basic  processing  are  determined  by  the  degree  of  the 
language’s  standardization. 

In  addition  to  intentional  design  differences  there  is  a  question  of 
whether  a  particular  translator  correctly  implements  the  intended  language.  For¬ 
mally  validating  compilers  for  modern  high-level  languages  is  not  possible.  Most 
commercial  compilers  are  subjected  only  to  some  series  of  empirical  tests.  If 
minor  differences  from  the  defined  language  are  detected,  manufacturers  may 
decide  to  document  the  deviations,  rather  than  pay  the  expense  of  trying  to 
correct  them.  These  deviations  may  affect  howr  well  a  software  system  reacts  to  a 
new  compiler. 


Even  if  the  syntax  of  a  language  is  standardized,  changes  may  be 
required  in  portions  of  the  code  which  do  the  translator-environment  processing. 


The  runtime  libraries  provided  by  the  compiler  suppliers  are  not  always  the  same. 
A  good  example  of  this  is  Pascal's  string  manipulation  routines.  While  the 
language  itself  does  not  define  string  types,  almost  all  implementors  include  them 
as  an  extension  to  the  language.  However,  the  format  used  by  each  is  not  stand¬ 
ardized  and  often  differs  among  compilers.  While  the  old  and  new  translators  may 
both  provide  functions  that  have  the  same  name  and  take  the  same  parameters, 
there  may  be  logical  differences  in  how  each  of  them  implements  these  functions. 
If  these  functions  perform  critical  operations  in  the  software  system,  it  may  be 
desirable  to  avoid  the  runtime-environment  processing  whenever  possible  and 
write  your  own  routines  instead. 

For  the  system-source-code  component  of  a  software  system,  the  changes 
necessitated  by  a  change  of  translators  is  determined  by  the  type  of  processing 
done  by  the  code.  There  is  usually  no  effect  on  the  operating-system-command 
component  of  the  software  system. 

3.  A  Change  of  Operating  Systems 

It  is  the  operating  system  which  provides  the  major  functionality  in  a 
computing  environment.  A  change  of  the  operating  system  therefore  is  the  most 
drastic  kind  of  porting.  Porting  software  to  a  new  operating  system  may  affect 
the  assembler-code  and  high-level-code  portions  of  the  svstem-source-code  com¬ 
ponent.  The  machine  code  (which  relies  only  on  the  underlying  machine)  does 
not  have  to  change.  The  most  direct  effects  of  changing  operating  systems  are  to 
those  code  sections  which  do  the  runtime-environment  processing.  If  the  new 
operating  system  does  not  provide  equivalent  functions  for  those  operations,  it 
may  become  necessary  to  redesign  the  logic  of  entire  sections  of  the  code. 

The  portability  of  a  software  system  may  also  be  complicated  by  the  fact 
that  a  change  of  operating  systems  requires  some  changes  to  the  translator  which 


the  software  system  has  used.  This  subject;  the  software  system  to  all  of  the  pos¬ 
sible  changes  it  would  have  to  undergo  for  any  other  change  of  translators. 
Therefore,  changing  operating  systems  has  an  indirect  effect  on  the  code  which 
does  the  translator-environment  processing  and,  possibly,  the  basic  processing  as 
well. 

Changing  operating  systems  obviously  affects  all  parts  of  the  operating- 
system-command  component  of  a  software  system.  Basic  commands  (e.g..  com¬ 
pile,  link,  search,  etc.)  are  almost  always  supported  in  some  form  by  the  new 
operating  system:  command  files  usually  are  available  as  well.  Therefore,  the 
changes  required  by  these  commands  are  a  matter  of  substituting  the  new  formats 
for  the  old.  The  greatest  difficulties  arise  if  operating-system  utilities  have  been 
utilized  and  the  equivalent  utilities  do  not  exist  in  all  operating  systems.  When 
they  do  exist,  their  formats  may  not  be  at  all  similar.  In  either  case,  an  extensive 
restructuring  may  be  necessary  to  maintain  the  software. 

The  porting  to  a  new  operating  system  may  require  major  changes  to 
both  components  of  a  software  system.  In  the  system-source-code  component,  the 
assembler  and  high-level  code  may  have  to  be  changed.  These  changes  may  affect 
the  code  which  does  any  of  the  three  types  of  processing.  For  the  operating- 
system-command  component,  a  major  rewriting  is  usually  necessary  for  all  three 
forms  of  operating-system  commands. 


III.  THE  IMPACT  OF  THE  MBDS  DESIGN  ON  PORTABILITY 


In  this  chapter  we  present  a  case  study  of  the  porting  of  a  particular  software 
system  from  one  computing  environment  to  another  computing  environment. 
Our  description  of  the  software  system  that  was  ported  follows  the  structure  of 
the  paradigm  presented  in  the  previous  chapter.  The  description  of  the  actual 
porting  also  follows  the  format  we  presented  in  the  previous  chapter  (i.e..  describ¬ 
ing  each  part  of  the  computing  environment  which  changed  and  how  the  change 
affected  each  component  of  the  software  system  that  was  ported). 

The  software  system  that  was  ported  for  our  case  study  is  the  multi- 
backended  database  system  (MBDS).  MBDS  is  a  database  system  (for  very  large 
databases)  that  was  developed  for  research  purposes  at  the  U.  S.  Naval  Postgra¬ 
duate  School.  The  basic  premise  of  MBDS  is  to  distribute  the  work  of  the  data¬ 
base  system  across  several  different  micro-computers.  MBDS  uses  one  computer 
as  the  system  controller,  and  several  other  computers  (at  present,  eight)  as  back¬ 
ends  to  accomplish  the  majority  of  the  required  database-manipulations.  There 
are  two  reasons  why  MBDS  was  chosen  for  our  case  study:  1)  MBDS  has  been 
ported  successfully  twice  since  its  initial  implementation,  and  2)  the  MBDS 
designers  have  established  portability  as  a  high  priority  since  the  initial  inception 
of  the  MBDS  project.  Including  the  first  implementation.  MBDS  has  been  run  in 
three  different  computing-environments.  Among  the  three  computing- 
environments.  there  have  been  four  different  hardware  configurations  (MBDS  uses 
more  than  one  computer  per  environment),  and  five  different  operating  systems. 
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To  attain  a  portable  software  system,  the  designers  of  MBDS  strived  to 
develop  the  MBDS  software  so  that  it  contained  a  high  degree  of  hardware  and 
operating-system  independence.  By  engineering  MBDS  with  a  minimum  amount 
of  dependencies,  they  greatly  enhance  the  probability  that  the  software  system 
would  be  easily  transportable  to  new.  and  varying,  hardware/operating-system 
configurations. 

To  develop  a  highly  portable  database  system,  the  designers  of  MBDS  first 
identified  which  portions  of  the  database  system  software  are  dependent  on  either 
the  hardware  and/or  the  operating  system.  They  identified  two  classes  of  data¬ 
base  system  software  which  are  dependent,  namely,  communications  software  and 
disk  input/output  software.  Communications  software  is  used  by  the  database 
system  to  communicate  among  different  computers  and  to  communicate  within  a 
computer,  referred  to  as  inter- computer  and  intra- computer  communications. 
respectively.  The  communications  software  is  often  affected  by  a  change  of  the 
operating  system  (since  communications  protocols  are  operating-system  depen¬ 
dent)  and  is  also  affected  by  a  change  of  the  hardware  (since  specialized  commun¬ 
ications  drivers  are  hardware  dependent).  The  disk  input/output  software  is  used 
by  the  database  system  to  access  and  process  information  from  the  secondary 
storage.  The  disk  input/output  software  is  also  affected  by  a  change  of  the 
operating  system  (since  it  is  operating-system  dependent)  or  by  a  change  of  the 
hardware  (since  it  is  dependent  on  specialized  disk  drivers). 

In  general,  there  is  no  way  to  avoid  a  certain  amount  of  hardware  and 
operating-system  dependencies  in  a  database  system.  Instead.  MBDS  was 
developed  with  techniques  which  can  minimize  the  effect  of  changes.  There  are 
two  distinct  approaches  to  accomplishing  this  task.  First.  MBDS  uses  the  con¬ 
cepts  of  abstraction  and  encapsulation  to  isolate  the  dependencies  of  the 


communications  and  disk  input/output  software.  The  database  system  software 
makes  calls  to  these  high-level  routines  that  are  dependent  on  the  programming 
language  used  in  the  software  system,  when  there  is  a  need  to  access  the  system- 
dependent  software.  These  calls  are  generic,  e.g..  send[message.  destination], 
receive[message.  sender],  do_disk_io[data.  device].  They  represent  abstractions  of 
the  actual  functions.  The  routines  themselves  (i.e..  send,  receive,  and  do  disk  io) 
are  used  to  encapsulate  the  system-dependent  software.  Second,  the  designers 
used  the  concept  of  a  virtual  interface  to  develop  independent  software  for  com¬ 
munications  and  disk  input/output.  The  aim  of  the  virtual  interface  is  to  utilize 
abstractions  provided  by  the  compiler  to  accomplish  a  particular  task.  These 
abstractions  are  usually  in  the  form  of  library  routines  for  the  programming 
language.  As  these  library  routines  are  supported  by  different  compilers  under 
different  operating  systems,  it  is  easy  to  transport  the  virtual  interface  from  one 
operating  system  to  another. 

MBDS  has  utilized  the  abstraction  and  encapsulation  concepts,  as  well  as  the 
creation  of  a  virtual  interface.  Abstractions  and  encapsulations  are  used  by  the 
MBDS  communications  software  to  provide  high-level  calls  to  send  and  receive 
messages  both  among  and  within  computers.  Since  MBDS  is  a  message-oriented 
system,  all  of  the  inter-computer  and  the  intra-computer  communications  are 
accommodated  by  the  abstractions  and  encapsulations.  These  techniques  are  also 
used  by  the  MBDS  disk  input /output  software  to  provide  a  high-level  interface 
for  reading  (writing)  information  from  (to)  the  secondary  storage.  In  addition, 
the  MBDS  designers  also  created  a  virtual  interface  for  disk  input /output 
software.  The  virtual  interface  depends  on  the  programming  language  constructs, 
and  is  used  to  provide  a  high-level,  operating-system-independent  paradigm  for 
performing  disk  input/output  via  text  files. 


In  the  next  section  we  take  a  closer  look  at  the  construction  of  MBD>  accord¬ 
ing  to  our  paradigm  of  a  software  system.  An  in-depth  description  of  the  MBDS 
design  can  be  found  in  Reference  1  and  Reference  2.  descriptions  of  the  implemen¬ 
tation  of  MBDS  can  be  found  in  Reference  3  and  Reference  4. 

A.  THE  MBDS  COMPONENTS 

The  system-software  component  of  MBDS  contains  only  high-level  code 
(there  are  no  sections  of  machine  code  or  assembler  code).  This  has  greatly 
enhanced  the  portability  of  the  MBDS  software  system.  The  MBDS  high-level 
code  (written  in  the  C  programming  language)  performs  all  three  types  of  process¬ 
ing  contained  in  our  paradigm  (i.e.,  basic,  runtime-environment  and  translator- 
environment  processing). 

The  basic-processing  operations  of  MBDS  are  the  normal  C  language  con¬ 
structs  which  would  be  found  in  any  C  program  (e.g..  for-loops.  while-loops,  if- 
then-else  statments.  etc.).  These  basic-processing  operations  carry  out  the  major¬ 
ity  of  the  processing  in  the  MBDS  software.  We  have  stated  in  the  previous 
chapter  that  portions  of  the  system-source-code  component  which  are  written  in 
high-level  code  and  perform  basic-processing  operations  are  inherently  portable. 
Therefore,  the  majority  of  the  MBDS  software  system  is  inherently  portable.  The 
portions  of  MBDS  which  do  runtime-environment-processing  are  those  sections  of 
high-level  code  which  perform  inter-computer  communications,  intra-computer 
communications,  disk  input/output  and  system-timer  operations. 

Translator-environment-processing  operations  in  MBDS  are  performed  by 
function  libraries  provided  with  the  C  compiler.  They  consist  essentially  of  rou¬ 
tines  for  performing  terminal  input /output  and  routines  for  the  extensive 
character-string  manipulations  which  the  MBDS  software  performs.  MBDS  also 


performs  some  disk  input  /  output  at  this  level,  when  dealing  with  hie"  used  for 
execution-trace  information  and  user  input.  All  of  the  manipulation  of  the 
database- files  is  done  at  the  runtime-environment  processing  level,  under  the  guise 
of  abstraction,  encapsulation  and  virtual  interface  techniques. 

The  system-software  component  of  MBDS  consists  of  over  eighteen-thousand 
lines  of  C  code.  In  order  to  implement  and  manage  such  a  large  software  system 
the  designers  of  MBDS  make  extensive  use  of  the  operating-system-command 
component  of  MBDS.  Operating  system  command-files  are  used  to  gather  the 
required  svstem-source-code  files  in  one  place,  compile  and  link  them  into  execut¬ 
able  files,  relocate  all  executable  files  in  one  area  for  later  execution,  and  then 
erase  any  intermediate  (temporary)  files  which  are  no  longer  needed.  In  addition, 
since  the  MBDS  software  system  consists  of  multiple  processes  running  across 
several  computers  (usually  five  processes  per  computer),  command  files  are  util¬ 
ized  to  initially  start  the  system  in  an  orderly  fashion. 

B.  PORTING  THE  MULTI-BACKENDED  DATABASE  SYSTEM 

This  section  discusses  the  actual  changes  made  to  the  MBDS  computing- 
environment  each  time  MBDS  was  ported,  and  the  effects  that  each  of  those 
changes  had  on  the  MBDS  software.  Each  time  MBDS  was  ported,  changes  were 
made  to  both  the  hardware  and  the  operating  system  at  the  same  time  (the  com¬ 
piler  also  changed,  because  of  the  new  operating  system).  For  the  sake  of  clarity, 
each  of  these  changes  is  discussed  independently. 

1.  Changing  the  MBDS  Hardware 

MBDS  has  had  three  different  hardware  configurations,  the  first 
configuration  is  the  original.  The  controller  for  MBDS  is  a  Digital  Equipment 
Corporation  (DEC)  VAX-11/780.  The  backends  are  two  DEC  PDP-ll/44s.  For 


the  database  store,  each  backend  utilizes  a  G7-megabvte  RM03  disk  drive.  Inter¬ 
computer  communications  is  accomplished  using  the  point-to-point  parallel  com¬ 
munications  link  (PCL).  a  0.5-megabit  bus.  Three  PCL's  are  utilized,  one  from 
the  controller  to  the  first  backend,  one  from  the  controller  to  the  second  backend 
and  one  between  the  two  backends. 

In  the  second  configuration  the  controller  for  MBDS  is  a  DEC  VAX- 
11/750,  the  backends  for  MBDS  are  eight  Integrated  Solutions  Incorporated  (ISI) 
Motorola  68020-based  workstations.  For  the  database  store,  each  backend  utilizes 
a  500-megabyte  Control  Data  Corporation  (CDC)  winchester- type  disk  drive. 
Communications  is  accomplished  using  an  Ethernet.  All  computers  (both  con¬ 
troller  and  backends)  share  the  same  Ethernet. 

For  the  third  configuration,  the  controller  for  MBDS  once  again  is  a 
DEC  VAX-1 1/780,  while  the  backends  are  upgraded  to  DEC  Micro Vax-IIs  The 
communications  bus  is  also  upgraded  to  a  DELXI.  with  DECNET  providing  the 
networking  software  interface.  Each  backend  has  a  7l-megabvte  DEC 
winchester-type  disk  drive. 

Since  all  of  the  MBDS  software  system  consists  of  either  high-level 
svstem-source-code  or  operating-system-commands,  we  can  expect  that  no 
changes  would  be  required  to  the  software  solely  because  of  a  change  of  the  under¬ 
lying  hardware.  That  is  in  fact  what  happened.  In  both  cases,  where  MBDS  was 
moved  from  one  piece  of  computing  hardware  to  another,  no  changes  had  to  be 
made  to  the  MBDS  system-source-code  (as  a  result  of  the  hardware).  There  were 
also  no  changes  required  the  operating-system-command  component  of  MBDS. 

2.  Changing  the  MBDS  Source-Code  Compiler 

A  change  of  compilers  was  experienced  by  the  MBDS  high-level  code  (by 
circumstance)  each  time  a  change  of  operating  systems  was  made.  In  the  original 
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MBDS  configuration  the  DECUS  C  compiler  was  used  for  high-level  code  which 
was  developed  on  the  PDP-11/44  computer  (using  the  RSX-ll/M  operating  sys¬ 
tem).  For  code  that  was  developed  on  the  VAX-11/780  computer  (using  the 
VMS  3.7  operating  system)  the  EUNICE  C  compiler  was  used  (EUNICE  emulates 
a  UNIX  environment  on  the  VMS  operating  system).  For  the  second  MBDS 
configuration,  the  UNIX  C  compiler  was  used  for  high-level  code  on  both  the 
VAX-11/750  (using  the  UNIX  4.2  BSD  operating  system)  and  the  ISI  worksta¬ 
tions  (also  using  UNIX  4.2  BSD).  In  the  third  version  of  MBDS  the  DEC  C  com¬ 
piler  on  Micro- Vax  IIs  was  used  (using  the  MVMS  4.1  operating  system).  This 
same  C  compiler  was  used  to  develop  high-level  code  for  the  VAX-11/780.  Since 
executable-code  generated  for  the  Micro-Vax  II  computer  is  upward  compatible 
with  the  VAX-11/780,  it  was  possible  to  develop  high-level  code  for  the  Vax- 
11/780  on  the  Micro Vaxs  and  then  copy  across  the  executable  files.  This  avoided 
any  risks  of  using  yet  another  C  compiler,  and  avoided  using  the  VAX-ll/780  for 
development  purposes  (since  the  VAX-ll/780  was  used  for  other  purposes  in 
addition  to  the  MBDS  research). 

Changes  to  svstem-source-code  (as  result  of  changing  compilers)  would 
normally  be  expected  in  sections  of  code  which  perform  translator-environment 
processing.  However  this  was  not  the  case  with  the  MBDS  software,  there  were  no 
changes  required  for  code  which  performed  translator-environment-processing. 
This  is  probably  because  the  origin  of  the  C  programming  language  is  closely  tied 
to  the  UNIX  operating  system.  Therefore,  most  developers  of  C  compilers  (for 
any  operating  system)  provide  compiler  libraries  which  are  copies  of  the  original 
UNIX  C  compiler  library. 

There  were  some  changes  required  in  the  MBDS  high-level  code  which 
performed  basic-process  operations  (as  a  result  of  the  new  compiler).  These 
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changes  were  required  when  the  MBDS  software  was  ported  from  the  second  to 
the  third  versions  (i.e..  from  the  UNIX  C  compiler  to  the  DEC  C  compiler). 
Though  the  actual  changes  required  were  simple  (and  were  needed  in  less  than 
twenty  lines  of  C  code),  the  time  required  to  determine  the  cause  of  the  problem 
was  considerable.-  Both  compilers  accepted  the  source  code  (they  just  interpreted 
it  differently),  so  there  were  no  error  massages  produced  at  compile  time.  Indica¬ 
tions  of  the  compilers'  differences  did  not  appear  until  the  new  executable  files 
were  run  and  the  new  version  did  not  work!  Keep  in  mind  that  a  new  compiler 
was  not  the  only  change  which  had  taken  place.  This,  along  with  the  fact  that  no 
problems  had  arisen  from  previous  compiler  changes,  and  that  the  problems  were 
in  sections  of  code  which  performed  basic-processing  (the  least  probable  area), 
served  to  create  a  difficult  debugging  problem. 

The  difficulties  apparently  resulted  from  differences  in  the  way  the  two 
compilers  assigned  precedences  when  multiple  C  language  operators  appeared  in 
one  line  of  code  (  the  C  programming  language  allows  certain  short  hand  coding 
constructs  to  save  typing  time).  The  only  changes  needed  were  to  remove  these 
short-hand  lines  of  code,  and  rewrite  them  in  a  manner  similar  to  the  way  they 
would  be  written  in  any  other  high-level  language  (e.g..  Pascal).  From  a  software 
engineering  point  of  view,  the  short-hand  coding  techniques  should  have  been 
avoided  anyway,  since  they  tend  to  be  very  cryptic,  making  the  resulting  source 
code  difficult  to  read  and  maintain. 

3.  Changing  the  MBPS  Operating  System 

Portions  of  the  MBDS  software  ha -  e  run  on  five  different  operating  sys¬ 
tems.  In  the  original  MBDS  configurations  the  controller  used  the  DEC  VMS  3.7 
operating  system,  while  the  backends  used  the  RSX-ll/M  operating  system.  For 
the  second  version  of  MBDS,  both  the  controller  and  the  backends  used  the  UNIX 
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4.2  BSD  operating  system.  In  the  third  version  of  MBDS.  the  VMS  4.2  operating 
system  was  used  for  the  controller,  with  MVMS  4.1  running  on  each  of  the 
backends. 

As  was  stated  in  the  previous  chapter,  a  change  of  operating  systems  is 
the  most  drastic  kind  of  porting  for  any  software  system.  The  MBDS  software 
changes  required  as  a  result  of  a  new  operating  system  accounted  for  the  vast 
majority  of  work  needed,  both  in  terms  of  time  spent  and  percent  of  the  MBDS 
software  which  had  to  be  modified.  While  all  of  the  MBDS  system-source-code 
which  performed  runtime-environment-processing  had  to  be  modified,  the  changes 
were  isolated  to  just  a  few  source  files.  This  was  a  result  of  the  abstraction  and 
encapsulation  techniques  used  by  the  MBDS  designers.  Therefore,  it  was  easy  to 
predict  the  majority  of  the  changes  which  must  be  made  to  accomplish  the 
porting. 

Some  minor  changes  must  be  made  to  sections  of  the  MBDS  code  which 
performed  system-timing  operations.  These  changes  consisted  mostly  of  changing 
the  names  of  functions  which  were  called  (from  operating  system  libraries),  and 
rearranging  the  order  of  some  parameters  to  those  functions.  The  majority  of  the 
system-source-code  changes  must  be  made  in  the  sections  of  code  which  perform 
communications. 

For  the  original  version  of  MBDS  three  different  methods  of  communica¬ 
tion  were  used  depending  on  whether  the  need  was  for  inter-computer  communi¬ 
cation.  intra-computer  communication  in  the  controller,  or  intra-computer  com¬ 
munication  in  a  backend.  Inter-computer  communication  was  accomplished  using 
a  point-to-point  parallel  communications  link.  In  the  backends,  intra-computer 
communication  (under  the  RSX-ll/M  operating  system)  was  accomplished  with 
shared  memory  techniques.  For  the  controller,  intra-computer  communications 
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(under  the  VMS  3.7  operating  system)  were  performed  using  VMS  mailboxes. 
When  the  MBDS  software  was  ported  ro  the  UNIX  operating  system  none  of 
these  communication  techniques  existed. 

Under  the  UNIX  operating  system,  all  communication  (inter-,  and 
intra-computer)  was  accomplished  using  UNIX  sockets.  This  meant  that  all  code 
which  performed  the  communications  had  to  be  changed.  Due  to  the  virtual- 
interfaces  which  MBDS  had  set  up.  these  sections  of  code  were  again  isolated  to 
just  a  few  source  files.  There  was  also  the  advantage  that  the  virtual- interfaces 
could  accomplish  all  three  types  of  communications  with  just  one  low-level  driver 
(UNIX  sockets).  However,  when  the  third  MBDS  version  was  implemented  it  did 
not  use  UNIX,  so  all  the  communications  drivers  again  had  to  be  changed. 

The  third  version  of  MBDS  used  VMS  mailboxes  (like  version  one’s  con¬ 
troller)  for  intra-computer  communication  in  both  the  controller  and  the  back¬ 
ends.  This  meant  that  the  source  code  which  had  been  used  in  version  one’s  con¬ 
troller  could  be  used  (virtually  unchanged)  for  version  three's  controller.  In  addi¬ 
tion.  it  could  be  used  for  the  backends  as  well  (with  only  minor  changes).  Inter¬ 
computer  communications  in  the  third  version  of  MBDS  were  accomplished  using 
DECNET.  Since  this  technique  had  not  been  used  in  any  previous  MBDS  ver¬ 
sions.  entirely  new  communications  drivers  must  be  written.  The  virtual-interface 
techniques  again  isolated  the  changes  to  just  a  few  files. 

The  operating-system-command  component  of  MBDS  was  rewritten  each 
time  MBDS  was  ported  to  a  new  operating  system.  There  are  in  excess  of  twenty- 
five  command-files  used  to  manage  the  implementation  of  the  MBDS  software. 
So.  while  the  required  changes  were  mechanical  in  nature,  they  required  a  great 
deal  of  time  to  accomplish  simply  because  of  the  number  of  files  which  were 
changed.  Even  though  the  controller  for  version  one  of  MBDS  ran  on  the  VMS 


operating  system  (like  the  controller  and  backends  of  version  three),  the  controller 
software  only  represents  about  twenty-five  percent  of  the  MBDS  software.  There¬ 
fore.  while  some  of  the  command  files  from  version  one  could  be  used  in  version 
three  (with  minor  modifications),  there  were  still  a  great  many  command  files 
which  were  rewritten. 
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IV.  A  CLOSER  LOOK  AT  THE  MBDS  PORT 


In  this  chapter  we  discuss  the  steps  necessary  to  transform  MBDS  version 
two  into  MBDS  version  three.  We  examine  the  porting  process  in  a  chronological 
order,  essentially  presenting  a  journal  of  the  activities  used  to  move  the  software. 
A  separate  detailed  discussion  is  presented  of  the  changes  made  to  the  MBDS 
communications  software  (which  underwent  the  greatest  changes).  First,  lets  look 
at  the  sequence  of  events  used  to  accomplish  the  porting. 


A.  THE  SEQUENCE  OF  EVENTS 

Porting  the  MBDS  software  from  one  system  to  another  has  entailed  several 
distinct  phases.  The  major  milestones  in  the  sequence  are  as  follows: 

•  transfer  the  MBDS  files  (of  source-code  and  operating-system  commands) 
from  the  old  computing  system  to  the  new  one. 

•  modify  the  operating-system-command  files  used  for  compiling  the  MBDS 
software. 

•  compile  the  source-code  files  and  correct  any  compile-time  bugs  which 
appear. 

•  modify  the  MBDS  intra-computer  communications  software,  and  implement 
an  intermediate  version  of  MBDS  with  a  controller  and  one  backend,  both 
running  on  the  same  computer, 

•  perform  run-time  testing  on  the  intermediate  system  to  ensure  the  actions  of 
the  implementation  are  logically  correct  (according  to  the  MBDS  design), 

•  modify  the  MBDS  inter-computer  communications  software  to  implement 
the  final  version  (MBDS  version  three). 

•  confirm  the  actions  of  the  final  version  are  logically  correct. 

While  some  of  these  phases  overlap  to  some  extent,  the  porting  sequence  is  clearer 
if  they  are  considered  separately. 
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The  file?  of  source-code  and  operating-system-commands  which  comprise 
MBDS  (version  two)  exist  on  one  of  the  ISI  workstations.  The  first  step  in  the 
porting  process  is  to  copy  all  of  the  files  to  one  of  the  Micro-Yaxs.  where  the 
development  of  MBDS  version  three  has  been  accomplished.  Since  the  computing 
systems  for  both  versions  of  MBDS  are  connected  to  a  common  local-network,  the 
files  are  copied  using  the  standard  communications  utilities  available. 

Once  the  are  were  on  the  new  system,  the  next  step  is  to  convert  the 
operating-system-command  files.  Since  the  command  files  are  needed  to  manage 
the  compilation  of  the  MBDS  source-code,  their  conversion  must  take  place  before 
the  compilation  of  the  system  begins.  Each  implementation  of  MBDS  contains 
six  independently  executed  programs  (or  processes)  for  the  controller  and  five 
independent  programs  (or  processes)  for  each  backend.  There  is  a  set  of  com¬ 
mand  files  for  each  of  the  independent  programs.  One  command  file  in  the  con¬ 
troller  source-code  (and  one  in  each  backend)  may  call  all  of  the  subordinate  com¬ 
mand  files,  and  in  this  way  the  entire  set  of  MBDS  processes  can  be  created  from 
the  top  level.  The  total  number  of  command  files  for  the  controller  and  backends 
(in  version  two)  is  approximately  twenty-five. 

The  command  files  in  MBDS  version  two  are  UNIX  makefiles.  These  have  a 
capability  for  tracking  which  source-code  files  have  been  modified  (and  which 
have  not)  since  the  last  time  a  program's  source-code  files  are  compiled  and 
linked.  Makefiles  also  allow  the  programmer  to  state  which  source-code  files  are 
dependent  on  other  source-code  files.  Through  makefiles,  only  modified  source- 
code  files  are  recompiled,  and  they  (and  files  dependent  on  them)  are  relinked. 
Some  of  the  MBDS  processes  require  over  thirty-five  source-code  files,  and  each 
shares  some  common  source-code  files  with  the  other  MBDS  processes.  Therefore. 


the  management  of  the  MBDS  software  is  easier,  ami  modifications  can  be  accom¬ 
plished  faster,  when  makefiles  are  used. 

Version  three  of  MBDS  uses  the  VMS  operating  system  which  does  not  have 
a  makefile  utility  available.  The  VMS  operating  system  provides  command  files, 
but  they  do  not  have  the  capability  of  tracking  source-code  modifications  and 
dependencies.  Therefore,  to  use  command  files  for  managing  the  implementation, 
not  only  must  all  of  the  makefiles  be  rewritten  but  the  logic  of  their  organization 
must  also  be  changed.  This  means  that  MBDS  version  three  requires  over  fifty 
command  files  to  manage  its  implementation,  more  than  twice  the  number  of 
makefiles  used  by  version  two.  Program  modifications  also  take  longer  since  it  is 
easier  to  recompile  and  link  all  source-code  files  needed  for  a  program  (even 
unmodified  ones),  than  to  manually  keep  track  of  which  have  changed  and  what 
files  are  dependent  on  them. 

In  order  to  avoid  the  problems  caused  by  not  using  makefiles,  an  initial 
attempt  has  been  made  to  utilize  the  EUNICE  environment  (on  the  VAX- 
11/780).  In  EUNICE  (a  software  system  that  emulates  UNIX)  makefiles  can  be 
used  to  compile  programs  which  run  on  the  VMS  operating  system.  However, 
while  the  programs  run  on  the  VAX-11/780  (with  VMS)  they  prove  to  be  not 
downward-compatible  to  the  Micro- Vaxes.  which  are  used  for  the  MBDS  back¬ 
ends.  (The  Micro-Vaxs  are  designed  to  be  upward-compatible  to  the  VAX- 
11/780.  but  not  vice  versa.)  Therefore,  the  makefiles  had  to  be  redone  as  com¬ 
mand  files. 

The  MBDS  command-files  are  converted  one  set  at  a  time,  as  each  set  is 
converted  an  attempt  is  made  to  compile  the  MBDS  process.  While  it  is  known 
(because  of  the  MBDS  design)  which  files  need  changes,  there  is  a  desire  to  see  if 
any  unexpected  compile-time  errors  might  occur.  No  compile-time  errors  emerged 
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some  warning  messages  have  been  generated  because  of  variable  name?  which  con¬ 
tain  too  many  characters.  These  are  truncated  by  the  compiler  but  do  not  cause 
any  problems  (the  truncated  length  happens  to  be  long  enough  to  maintain 
uniqueness).  Once  each  of  the  processes  is  compiled,  what  essentially  exists  is  a 
version  of  MBDS  with  program  segments  executable  on  the  VMS  operating  sys¬ 
tem.  but  still  only  able  to  communicate  with  each  other  using  the  UNIX  commun¬ 
ication  facilities.  Obviously,  the  next  step  in  the  porting  is  to  modify’  the  source 
code  which  performs  communications. 

As  we  stated  in  previous  chapters.  MBDS  performs  two  types  of  communica¬ 
tion.  intra-computer  and  inter-computer.  With  the  UNIX  operating  system  (used 
by  MBDS  version  two)  both  types  of  communications  are  accomplished  in  the 
same  manner.  The  VMS  operating  system  (used  by  MBDS  version  three)  uses 
different  means  to  accomplish  each  of  the  two  types  of  communication.  The  deci¬ 
sion  is  made  to  modify  the  MBDS  communications  software  in  two  phases.  In  the 
first  phase,  an  intermediate  version  of  MBDS  is  created  which  utilized  only  one 
computing  system,  supporting  both  the  controller  and  one  backend.  From  a  func¬ 
tional  point  of  view,  the  controller  and  each  of  the  backends  does  not  know  where 
the  other  components  are  executing. 

Since  the  intermediate  version  only  used  one  computer,  there  is  only  a  need 
to  modify  the  intra-computer  communications  at  that  point.  Version  three  of 
MBDS  uses  VMS  mailboxes  for  intra-computer  communications  in  the  controller 
and  backends  (like  the  version  one  controller).  For  the  intermediate  version,  the 
sections  of  code  which  normally  perform  inter-computer  communications  can  call 
the  same  virtual  communication  interfaces  as  the  intra-computer  communications. 

When  an  attempt  is  made  to  test  the  intermediate  MBDS  version  the  first 


unexpected  problems  arise.  After  a  considerable  debugging  effort  the  problem  is 
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isolated  to  three  lines  of  source  code.  The  problem  is  isolated  in  the  sense  that  it 
is  known  to  occur  in  a  particular  line,  but  it  is  not  obvious  why  it  occurred.  By 
all  observations  the  code  is  correctly  written,  and  it  has  functioned  properly,  as  is. 
in  version  two.  Eventually,  it  is  suggested  that  the  code  might  be  correct  to  the 
human  observer  but  is  being  incorrectly  interpreted  by  the  compiler.  The  lines  of 
code  in  question  use  some  short-hand  coding  techniques,  which  has  apparently 
complicated  parsing  them.  The  lines  of  code  causing  the  problem  looked  like  this 
(the  problem  areas  are  in  bold): 

while  (msg_q[(*index)j  !=  0) 

data[j++]  =  msg  q[(*index)-f+J: 

data[jj  =  msg_q[(  ’"index )++]: 

They  are  modified,  to  remove  the  short-hand  techniques,  resulting  in  the  code 
shown  below  (note  the  need  for  two  additional  lines  of  code): 

i  =  *index; 

while  (msg  qji]  !=  0) 

data[j++]  =  msg_q[i-(— fj: 

datafjj  =  msg_q[i-M-]: 

■"index  =  i; 

Once  these  changes  are  made  the  section  of  code  functions  properly,  similar 
changes  are  needed  in  three  other  sections  of  the  source-code.  These  are  the  only 
changes  that  have  been  required  to  get  the  intermediate  version  of  MBDS  working 
properly. 

The  next  step  is  to  modify  the  inter-computer  computer  communications. 

Since  the  UNIX  version  does  not  have  separate  interfaces  for  inter-computer  com- 
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munications.  these  are  not  actually  modifications.  Instead,  entirely  new  interfaces 


must  he  created  for  VMS  inter-computer  communications.  MBDS  version  three 
uses  DECNET  software  to  perform  the  inter-computer  communication.  These 
interfaces  (as  well  as  the  ones  for  the  VMS  intra-computer  communication)  are 
discussed  further  in  the  next  section.  After  the  inter-computer  communication 
interfaces  are  completed  the  only  task  remaining  is  to  perform  some  final  testing. 
No  additional  modifications  are  necessary  to  create  MBDS  version  three. 

B.  THE  MBDS  COMMUNICATION  INTERFACES 

Before  proceeding  further  with  any  discussion  of  modifying  the  MBDS  com¬ 
munication  interfaces,  we  first  present  a  general  overview  of  the  MBDS  software 
architecture  and  how  it  utilizes  the  communication  interfaces.  As  we  have  stated 
before,  each  MBDS  implementation  has  a  controller  and  one  or  more  backends. 
The  controller  is  comprised  of  six  processes,  and  each  of  the  backends  has  five 
processes.  In  a  normal  implementation  the  controller  (i.e..  its  six  processes)  is  run 
on  its  own  computing  system,  there  is  also  a  separate  computing  system  for  each 
backend.  Since  each  process  is  an  independently  run  program  it  has  no  direct 
connection  to  any  other  process,  yet  the  processes  must  pass  messages  (informa¬ 
tion  and  data)  to  each  other  for  MBDS  to  operate.  Within  each  process  there  are 
the  virtual  interfaces  for  sending  and  receiving  messages,  it  is  these  send  and 
receive  routines  which  must  actually  be  modified  whenever  MBDS  is  ported.  The 
send  and  receive  routines  only  perform  the  intra-computer  communication. 

Of  the  six  processes  in  the  controller  only  four  are  needed  by  MBDS  for  data¬ 
base  operations,  the  other  two  processes  are  used  for  inter-computer  communica¬ 
tion.  The  same  is  true  for  each  backend,  that  is.  only  three  of  the  backend 
processes  are  used  for  database  operations,  the  other  two  are  for  inter-computer 
communication.  These  processes  (in  the  controller  and  each  backend)  operate  as 


the  virtual  interlaces  for  inter-cornputer  communication  To  avoid  confusion  with 
the  intra-computer  interfaces  we  call  these  processes  get-net  and  put-net  las 
opposed  to  send  and  receive).  Excluding  the  get-net  and  put-net  processes,  all 
MBDS  database-processes  perform  only  intra-computer  communication.  The 
pseudocode  for  any  MBDS  database-process  (at  a  very  high  level)  looks  like  this  : 


While  MBDS  is  operating  do 

Receive  a  message 

Perform  any  required  processing 

Send  any  required  response 

From  looking  at  the  pseudo  code  you  might  wonder  how  messages  ever  get  from 
one  backend  to  another,  or  from  a  backend  to  the  controller.  The  answer  is  in  the 
last  line  of  the  pseudo  code,  the  key  word  is  required.  The  required  response  mat- 
mean  sending  a  message  to  more  than  one  other  process,  if  one  of  those  processes 
is  the  put-net  process  then  the  message  eventually  goes  to  a  process  on  another 
computing  -system.  Therefore,  the  pseudocode  for  the  put-net  process  looks  like 
this: 

While  MBDS  is  operating  do 

Receive  a  message 

Put  it  to  the  appropriate  process 

The  appropriate  process  to  which  a  message  is  put  is  always  a  get-net  process  on 
another  computer  system.  The  pseudo  code  for  a  get-net  process  looks  like  this: 


While  MBDS  is  operating  do 
Get  a  message 

send  it  to  the  appropriate  process 


Now'  lets  examine  how  the  MBDS  intra-computer  communication  interfaces  (send 
and  receive)  have  been  modified  to  operate  under  the  VMS  operating  system. 
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1.  Modifying  the  Intra-Computer  Communications 

The  controller  for  MBDS  version  one  uses  the  same  V.VX-11/780  as  the 
controller  for  MBDS  version  three.  While  version  one  runs  on  VMS  3.7  and  ver¬ 
sion  three  runs  on  VMS  4.2.  the  intra-computer  communication  facilities  provided 
by  the  two  VMS  releases  are  the  same.  Therefore,  the  MBDS  version  one  con¬ 
troller  communication  interfaces  can  be  used  for  the  MBDS  version  three  con¬ 
troller  without  modifications,  and  can  be  used  for  the  version  three  backends  with 
only  minor  modification. 

In  the  VMS  operating  system,  intra-computer  communication  is  accom¬ 
plished  with  VMS  mailboxes.  These  mailboxes  are  virtual  devices  which  can  be 
created  through  the  operating  system.  When  a  program  calls  the  operating  sys¬ 
tem  to  create  a  mailbox,  the  program  must  specify  a  logical  name  to  be  assigned 
the  mailbox.  The  operating  system  then  creates  a  mailbox,  with  the  specified 
logical  name,  and  pro-  ides  the  program  with  a  logical  channel  to  the  mailbox. 
Once  a  mailbox  is  created  messages  may  be  put  into  it  (or  taken  out  of  it)  by 
writing  to  (or  reading  from)  the  logical  channel  provided  by  the  system.  If  a  call 
is  made  to  the  operating  system  to  create  a  mailbox  with  a  logical  name  that  has 
already  been  used,  no  new  mailbox  is  created,  the  operating  system  just  provides 
another  logical  channel  to  the  already  existing  mailbox.  This  is  how  different 
processes  on  the  same  computer  can  communicate.  If  several  processes  all  use  the 
same  logical  name  in  a  create-mailbox  call  to  the  operating  system,  then  they  all 
share  the  same  mailbox. 

The  MBDS  intra-computer  communication  (using  mailboxes)  is  accom¬ 
plished  by  having  each  process  in  the  controller  lor  backend)  create  a  mailbox 
with  its  own  logical  name,  and  mailboxes  with  the  logical  names  for  each  of  the 
other  processes  in  the  controller  (or  backend).  The  logical  names  are  standardized 
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for  all  controller  (and  backend)  processes.  As  we  have  said,  if  the  same  logical 
name  is  used  more  than  once,  multiple  mailboxes  are  not  created.  Rather,  only 
multiple  channels  to' the  mailbox  with  that  logical  name  are  created.  Therefore, 
when  all  processes  in  the  controller  (or  backend)  have  finished  with  their  create- 
mailbox  calls,  there  is  one  mailbox  for  each  process  in  the  controller  (or  backend). 
Each  process  has  a  logical  channel  to  its  own  mailbox,  and  logical  channels  to  the 
other  processes’  mailboxes.  The  protocol  that  MBDS  uses  to  make  this  scheme 
work  is  that  processes  can  ofily  read  their  own  mailboxes,  and  can  only  write  to 
other  processes’  mailboxes.  There  is  no  need  to  write  to  their  own.  or  read  from 
any  one  elses. 

The  MBDS  version  one  controller's  intra-computer  communication 
software  is  used  without  changes  for  the  controller  in  MBDS  version  three.  To 
create  the  version  three  backend  intra-computer  communication  software,  it  is 
only  necessary  to  use  a  copy  of  the  controller  software  with  the  controller  logical 
names  (for  the  mailboxes)  changed  to  backend  logical  names. 

To  create  the  intra-computer  communications  software  for  the  inter¬ 
mediate  MBDS  version  (i.e..  where  the  controller  and  backend  run  on  a  single 
computer  together),  one  additional  (temporary)  change  is  made.  An  additional 
mailbox  is  created  for  the  get-net  and  put-net  routines  in  the  backend  and  the 
controller.  (Actually,  only  additional  channels  to  existing  mailboxes  are  created.) 
Normally,  a  controller  process  only  has  channels  to  mailboxes  for  controller 
processes,  and  backends  only  have  channels  to  backend  processes.  For  the  inter¬ 
mediate  version,  put-net  in  the  controller  had  a  channel  to  get-net's  mailbox  in 
the  backend,  and  vice  versa.  This  allowed  the  get-net  and  put-net  routines  to  use 
the  same  virtual  interfaces  that  are  used  by  the  send  and  receive  routines  (which 
perform  all  of  the  intra-computer  communication).  For  the  final  version  of 
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MBDS  (version  three),  put-net  and  get-net  no  longer  use  mailboxes  for  communi¬ 
cation.  This  is  because  the  VMS  operating  system  does  not  allow  logical  channels 
to  be  established  to  a  mailbox  in  another  computer. 

2.  Creating  the  New  Inter-Computer  Communications 

MBDS  version  three,  like  version  two.  uses  Ethernet  communication 
hardware  to  connect  the  controller  to  the  backends  (and  the  backends  to  each 
other).  However,  from  a  functional  viewpoint,  MBDS  version  three's  inter¬ 
computer  communication  software  operates  more  like  MBDS  version  one  (which 
used  point-to-point  communication  hardware).  This  is  because  the  way  DECNET 
(VMS)  communication  software  operates  it  does  not  provide  a  broadcasting  capa¬ 
bility.  DECNET  is  the  operating  system  software  used  for  the  version  three  inter¬ 
computer  communications. 

In  the  UNIX  (Ethernet)  environment  all  processes  that  wish  to  commun¬ 
icate  simply  associate  themselves  with  the  network,  each  process  then  has  a  logical 
communication  link  with  all  of  the  other  processes  that  are  associated  with  the 
network.  (This  is  much  the  same  as  when  processes  under  VMS  associate  them¬ 
selves  with  a  common  mailbox,  for  intra-computer  communication.)  However,  in 
the  DECNET  (Ethernet)  environment  each  process  must  establish  a  separate  logi¬ 
cal  link  for  every  other  process  it  wants  to  communicate  with,  therefore,  this  is 
essentially  (software)  point-to-point  communication. 

When  using  the  DECNET  software,  all  processes  which  communicate 
with  each  other  are  either  source  processes,  or  target  processes.  A  source  process 
is  one  that  initiates  a  request  to  establish  a  communication  link  with  another 
process,  the  target  process  is  the  one  that  receives  the  request.  A  given  process  can 
be  the  target  for  a  communication  link  with  one  process,  and  the  source  for  a 
communication  link  with  another.  The  DECNET  software  requires  that  a  target 


process  is  in  execution  before  its  source  process  requests  the  communication  link. 
A  requirement  like  this  does  not  exist  for  inter-computer  communication  in 
MBDS  version  one.  or  version  two  (nor  does  it  exist  for  intra-computer  communi¬ 
cation.  in  any  version).  Therefore,  the  logic  for  the  put-net  and  get-net  processes 
in  version  three  must  be  completely  changed. 

In  order  to  establish,  and  maintain,  communication  under  the  DECNET 
software  the  get-net  and  the  put-net  processes  must  operate  under  the  following 
constraints: 

•  any  process  which  is  a  target  must  be  executing  before  its  source  process 
attempts  to  establish  communication, 

•  if  a  process  is  to  have  multiple  communication  links,  where  it  is  a  target  in 
some  cases,  it  must  be  capable  of  maintaining  communication  on  established 
links,  while  still  waiting  for  (or  accepting)  any  links  where  it  is  the  target, 

•  a  target  process  must  inform  the  operating  system  (through  DECNET)  of 
the  network  name  it  is  using,  so  that  DECNET  can  properly  route  connec¬ 
tion  requests, 

•  a  source  request  must  know  the  network  name  for  all  of  its  target  processes, 
and  it  must  know  the  name  of  the  computer  (the  nodename  )  that  each  tar¬ 
get  executes  on. 

•  a  process  must  know  the  total  number  of  communication  links  it  should 
have,  how  many  it  is  ;  target  for.  and  how  many  times  it  is  a  source.  (This 
is  because  MBDS  conngures  the  number  of  backends  to  be  used,  on-the-flv. 
when  it  is  started.) 

Now  let  us  review  how  the  get-net  and  the  put-net  routines  for  MBDS  version 
three  were  organized  to  meet  these  criteria. 

In  the  MBDS  controller,  both  the  get-net  and  the  put-net  processes  are 
always  source  processes.  Therefore,  when  MBDS  is  initially  started,  the  controller 
processes  are  executed  after  all  of  the  backend  processes  are  executed.  This 
satisfies  the  target/source  ordering  for  the  controller-to-backend  communication. 
As  soon  as  the  controller  is  informed  (by  the  user)  how  many  backends  are  to  be 
used  the  get-net  and  the  put-net  routines  can  begin  establishing  (requesting)  com¬ 
munication  links.  Since  the  controller  (get-net  and  put-net j  communication 
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routine*,  are  never  targets,  they  do  not  have  to  inform  DECXET  of  any  network 
names  (they  do  not  need  network  names).  Also,  since  they  are  never  targets,  they 
do  not  have  a  requirement  to  accept  a  connection  request  while  communicating 
(they  never  accept  connection  requests).  When  requesting  the  communication 
links,  get-net  and  put-net  know  the  names  of  the  processes  they  communicate 
with  because  the  MBDS  process  names  are  standardized.  In  order  for  them  to 
know  the  computer  systems  (nodenames)  that  the  backends  are  executing  on.  the 
nodenames  are  standardized  &s  well. 

Each  nodename  consists  of  a  character  string  that  ends  with  a  number 
(e.g..  CSMVl.  or  CSMV2).  only  the  numbers  at  the  end  are  different.  The  con¬ 
vention  used  by  MBDS  is  that,  if  only  one  backend  is  used,  it  is  on  the  computer 
with  the  lowest  nodename  (i.e..  CSMVl).  if  multiple  backends  are  used  they  are 
on  the  computers  with  the  lowest  consecutive  nodenames  (e.g..  for  three  backends: 
CSMVl,  CSMV2.  and  CSMV3).  As  soon  as  the  controller  routines  know  the 
number  of  backends,  they  can  construct  the  proper  nodenames. 

For  the  MBDS  backend-to-backend,  inter-computer  communication  the 
backend  get-net  processes  are  always  targets,  and  the  backend  put-net  routines 
are  always  the  source.  Remember  that  backend  put-net  processes  are  targets  for 
controller-to-backend  communication,  they  are  the  only  processes  which  perform 
both  as  targets,  and  sources,  depending  on  the  situation.  Since  there  is  always  a 
single  controller,  the  backend  put-net  process  knows  it  is  a  target  for  a  single  com¬ 
munication  link.  The  backend  put-net  process  does  not  begin  requesting  links 
(acting  as  source)  to  the  other  backends  get-net  processes  until  after  it  has 
received  its  first  message  from  the  controller.  By  convention,  this  first  message  is 
always  the  number  of  backends  to  be  used.  The  put-net  process  then  knows  how 
many  communication  links  it  must  have,  and  where  it  is  the  source.  The  put-net 


process  forwards  this  message  (using  the  intra-computer  communication)  to  its 
respective  get-net  process.  and  then  the  get-net  process  knows  how  many  times  it 
must  act  as  a  target  for  a  communication  link.  The  backend  put-net  routines 
determine  nodenames  (for  the  other  backends  computer  systems)  in  the  same 
manner  used  by  the  controller.  When  the  backend  get-net  and  put-net  routines 
are  first  executed,  they  inform  DECNET  of  the  (standardized)  network  names 
that  are  being  used. 

Because  the  backend  communication  processes  (get-net  and  put-net)  act 
as  target  tasks  with  multiple  communication  links,  they  must  be  capable  of  main¬ 
taining  the  communications  on  any  established  links  while  waiting  for  (or  accept¬ 
ing)  connection  requests.  They  accomplish  this  by  using  VMS  mailboxes,  these 
are  the  same  types  of  mailboxes  used  for  intra-computer  communication.  How¬ 
ever.  in  this  case,  the  mailboxes  are  not  used  for  MBDS  messages,  but  are  used  for 
DECNET  status  information.  When  a  process  uses  DECNET  to  perform  com¬ 
munication  it  establishes  a  logical  link  to  DECNET.  This  is  in  addition  to  the 
logical  links  for  the  other  processes  that  it  communicates  with.  Any  time  a  pro¬ 
cess  establishes  a  logical  link,  the  process  has  the  option  of  associating  a  mailbox 
with  that  logical  link.  One  mailbox  may  be  associated  with  multiple  links. 

If  a  communication  link  has  a  mailbox  associated  with  it.  DECNET 
places  network  status  messages  (about  that  link)  into  the  mailbox.  These  status 
messages  may  include  information  such  as  the  fact  that  DECNET  has  a  connec¬ 
tion  request  for  a  process,  the  fact  that  an  established  link  has  received  a  message, 
or  the  fact  that  a  process  on  the  other  end  of  a  communication  link  has  discon¬ 
nected  itself.  Therefore,  the  backend  communication  processes  can  handle  multi¬ 
ple  Links  by  associating  a  single  mailbox  with  all  of  their  communication  links. 
Each  time  the  process  completes  an  operation  (e.g..  putting  a  message,  getting  a 


message,  or  accepting  a  connection  request)  it  then  reads  its  mailbox.  The  next 
message  in  the  mailbox  determines  what  operation  the  process  must  perform  next. 
DECNET  automatically  queues  multiple  messages  in  the  mail  box.  If  a  process’ 
mailbox  is  empty  the  process  waits  until  a  message  arrives,  that  is.  an  empty 
mailbox  means  there  is  nothing  else  for  a  process  to  do. 

Mailboxes  are  used  for  managing  multiple  connections  by  all  of  the 
MBDS  inter-computer  communication  processes  which  act  as  targets,  or  as 
message-receiving  processes.  Therefore,  the  put-net  process  in  the  controller  is  the 
only  one  that  does  not  need  a  mailbox  to  manage  its  communications  (it  is  never 
a  target,  and  only  puts  messages).  By  convention,  any  time  a  process  puts  an 
inter-computer  MBDS  message  to  another  process  it  also  puts  a  DECNET 
notification  message  to  the  same  process  (these  are  optional  with  DECNET.  and 
not  generated  automatically).  The  MBDS  message  goes  on  the  logical  communi¬ 
cation  link,  and  the  notification  message  is  placed-  (by  DECNET)  into  the  mailbox 
for  that  communication  link,  at  the  receiving  process.  If  the  DECNET 
notification  message  were  not  sent  the  receiving  process  would  never  be  prompted 
to  look  at  the  communication  link  for  a  message. 


V.  SUMMARY  AND  CONCLUSIONS 


In  this  thesis  we  have  focused  on  three  major  areas  of  work.  First,  a  para¬ 
digm  for  a  software  system  has  been  presented,  and  we  have  examined  how  the 
components  in  the  paradigm  relate  to  the  portability  of  the  software  system.  Let 
us  review-  the  general  issues  of  software  portability  discussed  in  the  previous 
chapters.  We  have  presented  a  paradigm  for  a  software  system  which  shows  that 
there  are  two  main  components  to  any  software  system,  the  system  source  code 
and  the  operatings  system  commands  used  by  the  software  system.  Each  of  these 
main  components  has  additional  sublevels.  For  the  system  source  code  there  are 
the  sublevels  of  machine  code,  assembler  language  and  high-level  code.  The  sub- 
levels  of  operating  system  commands  are,  basic  commands,  command  files,  and 
utilities.  We  have  also  stated  that  there  are  three  parts  to  a  computing  environ¬ 
ment  which  a  software  system  interacts  with,  the  hardware,  the  translator  (used 
by  the  source  code  for  the  software  system)  and  the  operating  system.  Finally,  we 
have  stated  that,  the  components  of  a  software  system  interact  with  the  parts  of 
its  computing  environment  through  three  types  of  processing,  basic  processing, 
translator  environment  processing,  and  runtime  environment  processing. 

Our  analysis  showed  that  the  ease  with  which  a  software  system  reacts  to 
porting  is  determined  by  three  factors: 

•  the  levels  of  system  source  code  and  operating  system  commands  used  to 
construct  the  system. 

•  the  types  of  processing  which  the  software  system  performs,  and 

•  the  parts  of  the  computing  environment  which  are  changed. 


In  general,  a  software  system  is  highly  portable  if  it  uses  only  high-level  code,  and 
if  it  avoids  runtime  environment  processing  whenever  possible. 

The  second  focus  of  the  thesis  has  examined  how  well  the  MBDS  software 
stands  up  to  porting.  To  construct  its  three  versions,  the  MBDS  software  has 
been  subjected  to  all  three  types  of  porting.  Each  time  the  system  was  ported, 
MBDS  ran  on  new  hardware,  had  a  new  operating  system  and  had  a  new  transla¬ 
tor  for  its  system  source  code.  Despite  the  drastic  changes  in  its  environment, 
MBDS  performed  extremely  Well  each  time  it  was  ported.  In  neither  case  did  the 
fundamental  MBDS  design  require  modification.  This  can  be  attributed  to  several 
factors.  First,  the  MBDS  software  is  written  entirely  in  high-level  code  and  the 
use  of  runtime  processing  has  been  avoided  except  where  absolutely  necessary 
(e.g.,  communications  and  disk  input/output).  Additionally,  any  processing 
which  might  complicate  portability  has  been  buffered  in  MBDS  through  the  use  of 
abstraction,  encapsulation  and  virtual  interfaces. 

The  third  focus  of  the  thesis  has  involved  the  details  of  the  MBDS  porting. 
The  major  work  of  porting  MBDS  has  involved  modifying  the  sections  of  code 
which  create  the  virtual  interfaces.  The  interfaces  themselves  have  not  been 
changed,  only  the  way  in  which  the  interfaces  accomplished  their  jobs  are 
modified.  These  changes  have  involved  the  MBDS  communication  software.  For 
the  inter-computer  communications,  the  MBDS  version  one  software  has  been 
modified  to  create  MBDS  version  three.  This  intra-computer  communication  is 
accomplished  using  VMS  mailboxes.  For  the  inter-computer  communications, 
entirely  new  communication  software  has  been  created  in  MBDS  version  three. 
The  VMS  DECNET  communication  drivers  are  utilized  for  the  inter  computer 
communications.  (Source  code  for  the  new  inter-computer  communication 
software  is  contained  in  the  appendixes  to  the  thesis.) 


In  addition  to  modifying  the  communication  interfaces,  creating  MBDS  ver¬ 
sion  three  has  also  required  modifying  all  of  the  operating  system  command  files 
used  to  manage  the  software.  This  involved  rewriting  the  UNIX  makefiles  (from 
MBDS  version  two)  as  VMS  command  procedures  (for  MBDS  version  three). 
Rewriting  the  command  files  has  been  the  most  time  consuming  task  in  the  port¬ 
ing  process. 

Overall,  MBDS  has  proven  to  be  easily  portable.  With  the  exception  of  some 
minor  problems  caused  by  the  way  the  new  compiler  parsed  some  lines  of  code  (in 
MBDS  version  three),  all  of  the  modifications  required  to  port  MBDS  have  been 
known  before  the  porting  began.  Additional  information  on  the  portability  of 
MBDS  can  be  found  in  [Ref.  l]  which  deals  with  the  process  of  porting  MBDS 
version  one  to  MBDS  version  two. 


APPENDIX  A  -  THE  MBDS  CONTROLLER  GET-NET  SOURCE  CODE 


r 

r  V  A  X  /  V  M  S  G  _  P  C  L  C 

r 


*/ 

*/ 

*/ 

*/ 

V 


-r  i  n c  1  ude 

<  s  t  d i o . h> 

r 

? i nc 1 ude 

< s  s de  f . h> 

r 

* i nc 1 ude 

< i ode  f . h> 

r 

* i nc 1 ude 

<ms  g  d  e  f . h  > 

r 

x i nc 1 ude 

<  d  v  i  d  e  f  .  h  > 

r 

* i nc 1 ude 

"  c  omnd  a  t  a  .  d  e  f 

it 

* i n  c 1 ud  e 

"ms  g . de  f  " 

* i nc 1 ude 

" flags. def" 

=  d  e  f i n  e 

MAXBE  16 

char 

netbuf  JMSGLEN]  ; 

char 

mbxbuf [MSGLEN] ; 

char 

msg  (MSGLEN)  : 

short 

net  chan; 

short 

mb  x  chan: 

short 

be  chan  [MAXBE  +  lj 

/ 

short 

be  dev [MAXBE  +  1 ]  ; 

short 

NoBac  k  end  s  ; 

struct 

ms  g  hdr  head; 

Standard  I/O  definition  * / 
VMS  -return  status  codes  * / 
VMS  I/O  return  codes  *  / 
DECNET  ms  g  definitions  */ 
\MS  device  definitions  '  j 
/*  MBDS  common  defs  '  / 

/*  MBDS  msg- type  defs  * / 
/*  MBDS  compile  flags  */ 
/*  max  num  of  backends  * / 

/*  network  buffer  */ 

/ *  ma  ilbox  buffer  */ 

/*  MBDS -msg  buffer  */ 

/*  channel  to  DECNET  */ 
/'  channel  to  ma  ilbox  * / 
;  /*  chan's  to  backends  */ 

*  backend  0  is  not  used  */ 

/ ’  device  n um  of  chans  *  / 
/ ’  the  n um  of  backends  */ 


/'  loopindex  ’  / 

/  ’  s  y s  t em  running  flag  ’  / 


K' 


V' 

I 


ma  in  (I 

{ 

i  n  t  i  . 

S  t  o  p  S  y  s  : 

char  NoBEs  (NoBElength  +  l] : 

/  *  init  intra-c  omp  u  t  e  r  c  onmu  nication  *  / 
mb  i n  i  t (  GPCLC  )  ; 

* i f  de  f  EnExF 1 ag 

printf ( "Enter  GPCL\n") ; 

f^end  i  f 

/  *  get  the  n umb er  of  backends  *  / 
i  f  de  f  pr  flag 

p r i n t f ( "Ge 1 1 i n g  number  of  backends  \  n" )  : 

#end  i  f 

rece i ve (msg ,  &head): 

5?  i  f  de  f  pr  flag 

m_prnt  (msg.  <khead); 

f- end  i  f 

if  (head . tvpe  !=  SetNoBEs) 

{ 

printf("**  Error  in  GPCLC.  first  msg  must  be  "): 
printf ("of  type  SetNoBEs  **\n"); 
printf("**  Type  =  %d  *  * \ n "  ,  head. type); 
m_prnt(&msg.  <khead): 
sleep (DELAY) : 
ex  i  t (  )  : 

} 

/ T  Extract  the  number  of  backends  */ 

for  (  i =0 ;  (  ( NoBEs  [  i  ]  =  ms  g [  i  ]  )  ! =  ’O'):  i  -H- )  : 

NoBackends  =  str  to  num(NoBEs): 

?ifdef  pr_flag 

p r i n t f (  "Numb  e r  of  backends=  %d , n " .  NoBackends): 

?iend  i  f 
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Ini:  net  wo  rk  connection'  to  P  PCL  s  in  backend? 
net  ini t (NoBackends ) : 

StopSvs  =  FALSE: 
wh  i  1 e  (  ! S  t  opSv  s  ) 

{ 

get  message (msg ,&head) ; 

switch  (head. type) 

{ 

/*  msg  type  for  msgs  from  EMg  t  (BEnds)  to  IIG  (ctller)  */ 

case (ReqFo  rNewDe  s  c I d )  : 

'  head. receiver  =  IIG: 
break : 

case(ClusId) : 
head. receiver  =  IIG: 
break ; 

/ *  msg  type  for  msgs  from  RecP  (BEnds)  to  PP  (cntrl)  */ 

c  a  s  e ( BC_Re  s )  : 
head. receiver  =  PP : 
break  ; 

c  a  s  e ( BC  AO  Res): 
head. receiver  =  PP : 
break  ; 

/ *  ms  g  type  for  ms  g  s  f  r  om  Re  c  P  ( BEn  d  > )  to  Re  qP  (cntrl)  *  / 

case (RetFetCause  dBvUpdRe  s )  : 
head. receiver  =  REQP : 
break  : 

c  a s  e ( Re c Chang  e dC 1 u  s )  : 
head. receiver  —  REQP : 
break  ; 

case(  NoMoreGenlns  )  : 
head. receiver  =  REQP: 
break : 
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type  for  ms  g  s  f  r  om  BEn  d  s  to  TI  |  c  t  1  1  e  r  ) 


ms  g 

case(Error) : 
head. receiver  =  TI: 
break : 

case (ErrorFree) : 
head. receiver  =  TI: 
break  ; 

case (GeTime  s )  : 
head. receiver  =  TI: 
break  ; 

c  a  s  e ( T i  m_A  r  r  _Emp  )  : 
h e ad . r e c e i v e r  =  TI : 
break ; 

case(Stop) : 

StopSys  =  TRUE:, 
break  ; 


default: 

printf(" In valid  message  type  "); 

p  r  i  n  t  f  (  "  enc  oun  t  e  r  ed  :  °cd  n  "  .  he  ad  .  t  vpe  )  : 

exit_gracefullv(): 


}/*  end  switch  *  / 


^ i f  de  f  p  r 
iend  i  f 


if  (  ! S  t  opSv  s  ) 

{ 

head. sender  =  G  PCLC: 
s  e  nd (ms  g  .  &he  ad  )  : 

flag 

m  prut  (msg.  &head) : 


} 


} / ‘  end  wh i 1 e  " j 

*i  f  de  f  EnExF 1 ag 

,  p  r i n  t  f ( " Ex i t  GPCL \ n " 
*  e  n  d  i  f 

} 
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routine  to  get  the  next  message  f  r  on:  the  network 

g  e  t  me s s  a  g  e ( mp  t  r  .  hpt  r  ) 

char  ’  mp  t  r  : 
struct  msg_hdr  ’hptr: 

{ 

i  n  t  s  t  a  t  . 

ms  glen, 
f  un c  . 

J  .  k: 

short  i o  sb [ 4  ]  : 
char  r c vbu f [MSGLEN  +  lj  , 
intbuf [ 2  1  =  "  0" . 
t  mp  s  t  r  [  5  j  : 

short  ms  g  r  e  c  : 

=  i f  de  f  EnExF 1 ag 

printf(" Enter  get  _me  s  s  a  g  e  -  n  "  )  : 

=  e nd  i  f 

/*  Check  mailbox  for  message  notices  */ 
read  mb  x ( mb  x  b  u  f  )  : 

/*  Read  the  message  * / 
read  net ( rcvbuf  .  mb  x  b  u  f  )  : 

/J  Get  the  header  information  * / 

k=0  ; 

/ *  get  sender  *  / 
for  ( j  =0 :  j  -  3 :  j  ++ ) 

t  mp  s  t  r  [  j  ]  =  rcvbuf  [  k  +4-  ]  : 

t  mp  s  t  r  [ j  ]  =  '  O’: 

hpt r-> sender  =  str  to  n  um(  tmp  s  t  r  )  : 

i ’  get  receiver  ‘  / 
for  (  J  =0  :  j  •  3  :  j  ++ ) 

t  mp  s  t  r  [ j  ]  =  rcvbufjk  -H-  j  : 

t  mp  s  t  r  [ j  ]  =  '  O'; 

hpt  r-  -receiver  =  str  to  n  um(  t  mp  str): 
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/  '  get  the  type  '  / 
for  (  j  =0  :  j  3  :  j  -H- ) 

tmp  s  t  r [ j  j  =  rcvbuffk  ++ ]  ; 
ttnp  s  t  r  [  j  ]  =  ’  O': 

hptr->type  =  s t r _t o_num(  tmp s t r )  : 

# i f  de  f  pr  flag 

ra_prnt ( rcvbuf .  hptr); 

??end  i  f 

/  *  copy  the  me  s  s  a  g  e  *  / 
j  =0  ; 

while  (  (k  <  MSGLEN)  ( rcvbuf [k]  !=  ECMs  g )  ) 

mptr[j++]  =  r  c  vbu  f  (  k++]  ; 

mp  t  r [ j ]  =  r  c  v  b  u  f [ k ]  ;  / *  get  ECMs  g  * / 

if  (k  >=  MSGLEN) 

printf  ('•*****  Value  of  MSGLEN  "); 
p  r i n  t  f ( "should  be  increased  *****\n"): 

# i f  de  f  EnExFl ag 

printf ("Ex  it  g e t  me  s s age \ n  ”  )  ; 

#end  i  f 

}  /*  end  get  me  s  s  a  g  e  * / 
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/  Routine  to  check  the  ma  i  1 b  o  x  for  me  ssage  notices  ’/ 

read  mb  x ( b  u  f ) 

char  *  bu  f  : 

{ 

short  ms  g  r  e  c  ; 
short  stat; 
short  i o  s  b [ 4  }  ; 

# i f  d e  f  EnExF 1 ag 

printf(" Enter  read  _mb  x \ n " )  : 

fend  i  f 

ms g  rec  =  FALSE; 

wh i  1 e  (  !  ms  g  _r  e  c  ) 

{ 

# i f  d  e  f  pr  flag 

p r i n t f ( "Ca 1  1  i ng  qio,  read  ma i 1  box \n " )  ; 

?endi  f 

stat=  sys$qiow(0,  mbx_chan,  10$  READVBLK. 

iosb,  0,0.  buf,  MSGLEN,  0,0. 0.0): 

£ifdef  pr_f lag 

p r i n t f ( "Re t u rned  from  qio  \ n " )  : 

fend  i  f 

if  ((stat  ! =  S S $  NORMAL )  ||  ( i o s b [ 0 ]  ! =  S S $  NORMAL ) ) 

{ 

printf("**  Ma  ilbox  read  error.  s  t  a  t  =  %d  (%x).  "): 

printf("iosb(0j=%d  ( %x )  **\n",  stat.  stat. 

i  o  s  b  [  0  ]  .  i  o  s  b  [  0  ]  )  ; 

exi t  graceful ly (  )  ; 

} 

sw i t  c  h  ( bu  f  j  0 ]  ) 

{ 

case  MSGS  _  INTMSG  : 

{ 

ms  g  rec  =  TRUE : 
break  ; 


case  MSGS  CONNECT : 

; 

i 

p  r  i  n  t  f ( " *  '  Ne  two  rk  connection  "): 
pr  in t  f ( "requested  ’  *  '  n  "  )  : 
p  r  i  n  t  f ( " * '  GPCLC  should  not  "): 
print("  receive  connect  req's  **  n" 
exit_gracefullv() ; 

} 

case  MSGS  CONFIRM:  break: 

default:  { 

printf("**  Network  error,  "): 
p r i n t f ( "mbxbu f  [  0 j  =  %d  (%x)  **  n". 

bu f ( 0 ]  ,  buf[0]) 

e  x  i  t  _g  r  a  c  e  f  u  1  1  y  (  )  : 

} 

}  /  *  end  switch  *  / 

}  / *  end  wh i 1 e  * / 

# i f  de  f  EnExF 1 ag 

printf("Exit  r e admbx \ n  "  )  ; 

fend  i  f 


}  l*  end  readmbx  */ 


/  '  Ro  utine  to  read  a  me  «  s  a  g  e  f  r  orn  a  backend 


read  net  ( rcvbuf .  mb  x  b  u  f ) 

char  ’rcvbuf ,  *mbxbuf; 

{ 

short  *  un  i  t  , 

BEnum. 
f  unc  , 
s  t  a  t  , 
i osb [ 4 ] : 

# i f  de  f  EnExF lag 

printf("  Enter  r  e  ad _ne  t \ n  "_)  : 

^endi  f 

un  i  t  =  mbxbu  f  : 

for  (  BEnum  =  1  :  be  dev  [  BEnum]  !  =  un  i  t  [  1  ]  :  BEnum-H-) 

{ 

if  (BEnum  =  NoBackends) 

{ 

pr  i  n  t  f  (  "  *  *  *'  Cannot  locate  unit  number  to  "): 
pr int ( " read  net  with.  *  *  * \ n " )  : 
printf(" ***  Searched  through  %d  backends."): 
p  r  i  n  t  f  (  "  *  *  *  n " .  BEnum)  : 

exit  graceful  1 y ( )  ; 

} 

} 

iifdef  pr_f lag 

p r i n t f ( "Ca 1  1  i ng  qio  read  from  backend  lTd  n ". BEnum)  : 

^end  i  f 

func  =  10$  READVBLK; 

stat=  svs$qi ow (0.  be_chan[ BEnum]  .  func.  i  o  s  b  . 

0.0.  rcvbuf.  MSGLEX .  0.0. 0.0): 

iifdef  prflag 

printf(" Re  turned  from  qio  n"): 


* e nd  i  f 


if  ((star  !  =  S  S  £  NORMAL )  ;  liosbO  !  =  S  S  $  NORMAL i ) 

{ 

p  r  i  n  t  f  (  "  ’  '  Read  error  be_chan  ccd  .  s  t  a  t  =  Scd  ( lr.x  )  .  "  )  :  J 

printf("iosb[Oi  =  %d(c/fcx)  *  *  n".  BEnum.  stat. 

stat.  i  o  s  b  [  0 ]  .  i  o  s  b [ 0 ]  )  : 

exit_gracefullv(): 

}  '  ‘  ; 
* i f  de  f  EnExF 1 ag 

p r i n t f ( "Ex i t  r e ad_ne t  \n " )  :  ’ 

?end  i  f 

}  /*  end  read_net  */ 


Routine  to  initial  iz  Dec  net  link?  to  each  backend 


net  _ini t ( XoBEs ) 

i n  t  XoBEs : 

{ 

i n  t  stat ,  i  ; 
short  iosb[4] ; 

char  nodespec[l28j.  tmp  s  t  r [ 5 ]  ; 

struct  sd  { 

i  n  t  1  e  n  : 
char  'pt  r  ; 

} 

n  e  t  n  am  =  {  5  .  "  NET : "  } . 
neb  =  {  0,  nodespec  }. 
netmbx  =  {  6.  "NETMBX"  }: 

long  d v i un i t  [  1  ]  ; 

short  dviunit  1 e n [  1  ]  : 

/*  structure  to  get  unit  numbers  for  chan's  to  net  */ 


struct  { 

short  len;  /*  buffer  length  */ 
short  code:  /’  item  code  */ 
long  "unit;  /*  addr  to  return  unit  to  */ 
short  "unitlen;  /*  length  of  unit  *  / 
long  nu 1  :  / *  end  of  descriptor  *  / 
} 


d  v i  =  { 4 .  DV I  $  UN IT.  dviunit.  dviunit  len.O}; 

«i f de  f  EnExF 1  a g 

p  r  i  n  t  f  (  "  En  t  e  r  n  e  t  _  i  n  i  t  \  n  "  )  : 

*  end  i  f 

/ *  create  a  ma  i  1 b  o  x  * / 

s  t  a  t  =s  y  s  $  c  r  embx  (  0  .  &mbx  chan.  MSGLEN.  MSGMAX. 

0  .  0 .  <fcn  e  t  mb  x  )  : 

if  (stat  ! =  S S $  NORMAL ) 

{ 

printf("**  Error  creating  ma  i  1 b  o  x .  " )  : 

printf("stat=  %d  ( %x )  **\n".  stat.  stat); 

exit  gracefullv(); 

} 


/'  assign  channels  to  the  net 
f  o  r  (  i  =  1  :  i  <  =  XoBEs  :  i  -H- ) 

{  • 

s  t  a  t  =  svstass  i  gn(  <kn  e  t  n  am .  <§cb  e  c  h  a  n  [  i  ]  .  0  .  &n  e  t  mb  x  )  : 

if  (stat  ! =  S  S  $  NORMAL ) 

{ 

printf("**  Error  in  assign  b  e  _  c  h  a  n  %d .  " ) : 

p  r i n  t  f ( ” s  t  a  t  =  %d  (%x)  *  * \ n " ,  1. stat. stat)  : 

exit _g raceful  1 y ( )  ; 

} 

}  /  *  end  for  i  *  / 

/*  Establish  logocal  link  */ 
for(i=l;  i  <=  NoBEs :  i++) 

{ 

/*  build  network  connect  block  */ 

strcpyfnodespec .  "CSMV" ) ; 

numt os t r ( i .  tmpstr); 

strcat  (nodespec,  tmpstr); 

strcat  (nodespec,  " :  :  \ " 0=PPCLB'  " " )  : 

t i f  de  f  pr_f 1 ag 

printf(" backend  %d  nodespec.  ' "%s ' " ,n".  i.  nodespec): 
lend  i  f 

neb ,  1 en=  s t r 1 en ( node  spec  )  ; 

/*  Request  the  connection  */ 

stat=  s  y  s  $  q i ow ( 0 ,  be  chan(i),  IOSACCESS.  iosb. 

0.0,0,  imeb.  0 . 0 . 0 . 0  )  : 

if  ((stat  !=  S  S  S  ^NORMAL  )  ||  (  i  o  s  b  [  0  )  !=  SS$  NORM.A.L  )  ) 

{ 

printf("**  Access  err  r  be  chan  %d .  s  t  a  t  =  %d  " )  : 
printf("(%x).  iosb[0]  =  %d  f%x )  *  * \ n " .  i  .  stat, 

stat.  iosb[0].  i  o  s  b  [  0 ]  )  : 

exit_gracefully(): 

} 


'  Get  unit  n  umb  er>  for  the  channels 
f  o  r  (  i  =1  :  i  <  .=  NoBEs  :  i  -r-r  i 

{ 

s  t  a  t  =  sys$getdvi(l.  be  chanji],  0.  &d  v  i  .  iosb. 0.0.0) 
if  ( s  t a t  ! =  S  S  $  NORMAL ) 

{ 

printf("**  Error  getting  channel  number  for  BE  " 
p  r  i  n  t  f  (  "%d  .  s  t  a  t  =  %d  ( )  *  *  n  "  .  i  .  s  t  a  t  ,  s  t  a  t  )  : 
exit_gracefullv(); 

} 

s  y  s  $wa i t  f  r (  1  )  : 
if  (iosb[0]!=  SS$  NORMAL ) 

{ 

printf("**  Error  getting  channel  number  for  "  )  : 
p  r i n  t  f ( " BE  %d .  i o  s  b [ 0 ] =  %d ( ^cx )  * ’  n " .  i  . 

iosb[0j.  i o  s  b [ 0 ]  )  : 

exit  graceful  1 v (  )  ; 

} 

be  d  e  v [  i ]  =  *  d  v i u  n i t  ; 

}  /  *  end  for  i  *  / 


4 i f  de  f  EnExF 1 ag 

printf("Exit  netinit'n"); 

*end  i  f 

}  / *  End  net  init  *  / 


routine  to  d  i  sconner  t  ail  network  links 


di sconnec  t  ( ) 

{ 

i  n  t  s  t  a  t  ,  i  : 

# i f  de  f  EnExF 1 ag 

printf(" Enter  Disconnect' n")  ; 

£end  i  f 

for  ( i =1 :  i  <=  NoBackends:  i-H-) 

{ 

#  i  f  de  f  pr_flag 

p r i n t f ( "Di s c onn e c t i n g  backend  %d  n " .  i); 

*end  i  f 

stat  =  sys $das sgn ( be_chan [ i )  )  : 
if  ( stat  !=  S S $  NORMAL ) 
printf("**  Dassign  Error  for  backend  %d  .  "): 

printf("stat=  %d  ( %x )  **\n" . i . stat .  stat): 

} 

# i f  de  f  EnExF 1 ag 

printf("Exit  Disconnect ' n" )  ; 

#end  i  f 

}  /*  End  disconnect  */ 


/*  Routine  to  close  network  connections,  then  abort  * / 

exit  g raceful iv() 

{ 

s 1 eep (DELAY) ; 
disc  onnec  t  (  )  ; 
ex  i  t  (  )  : 

} 
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APPENDIX  B  -  THE  MBDS  CONTROLLER  PUT-NET  SOURCE  CODE 


iinc 
sine 
*inc 
iinc 
®inc 
*  i  n  c 
iinc 
sine 

*de  f 
ide  f 
ide  f 

char 

char 

s  ho  r 


s  ho  r 
s  ho  r 


r 

r  V  A  X  /  V  M  S  P  _  P  C  L  C 

r 


7 

7 

7 

7 

V 


1  ude 

<  s  t  d i o . h> 

/ 

*  Standard  I/O  definition 

*7 

1  ud  e 

<s  sde  f . h> 

/ 

*  VMS  return  status  codes 

V 

1  ud  e 

< i od e  f . h> 

/ 

*  VMS  I/O  return  codes 

V 

1  ude 

<ms  gde  f . h> 

/ 

*  DECNET  msg  definitions 

V 

1  ude 

"  c  onmd  a  t  a  .  d  e  f 

W 

/*  MBDS  corrmon  defs 

"/ 

1  ude 

"ms  g . d  e  f " 

/ *  MBD  S  ms  g-tvpe  defs 

7 

1  ud  e 

"f  lags .def" 

/ *  MBD  S  c  omp  i  1 e  flags 

7 

1  ude 

"beno.de  1  " 

/*  backend  num  decl 

7 

i  ne 

MAXBE  16 

/*  max  num  of  backends 

7 

i  ne 

TRUE  1 

i  ne 

FALSE  0 

netbuf  [MSGLEN]  ; 

/ *  ne  twork  buffer 

7 

msg  [MSGLEN]  : 

/*  MBDS -msg  buffer 

7 

t 

be  chan  [MAXBE  + 

l] ;  /*  chan's  to  backends 

7 

/*  backend  0  is  not  used 

7 

t 

be  dev  [MAXBE  + 

1 

j;  / *  device  n um  of  chans 

7 

t 

NoBac  kends  : 

/*  the  num  of  backends 

7 

struct 


ms  g  hdr 


head: 


1*1 

i 

vi 

v1 


i 


i 

*•« 


int  StopS  ys.i.j.k: 

char  NoBEs  [  No  BE  1  en  g  t  h  -f  1  ]: 

# i f de f  En Ex Flag 

printf(  "Enter  PPCL'n"  ); 
lend i f 

/  *  init  intra-c  omp  u  t  e  r  c  onrnu  nication  *  / 

mb  i n i t (  P  PCLC  )  : 

/*  receive  a  message  from  a  controller  */ 

/*  task  into  ppcl's  mailbox  */ 

r  e  c  e i v  e ( &ms  g [ 0 ]  .  &h  e  a  d )  : 

/  *  The  first  me  ssage  should  type  Set  BEn  o .  * / 

if(  head. type  !=  SetNoBEs  ) 

{ 

printf(  "Error  in  PPCL .  1st  message  "): 
p  r  i  n  t  f (  "mu  s  t  be  of  type  SetNoBEs"  ); 
p  r  i  n  t  f  (  "  Type  =  %d  \ n " .  head. type  ); 

ms  e  n  d  ( &ms  g  [  0  ]  .  <kh  e  a  d  )  : 
abo  r  t ( )  : 

} 

/*  send  num  of  BE  to  GPCLC  */ 
head. sender  =  P  PCLC: 
head. receiver  =  G  PCLC; 
send(Amsg[0] .  &head); 

/ *  Extract  the  NoBackends  */ 

f  o  r (  k=0 ,  j  =0 ;  ( NoBEs [ j ]  =  ms  g [ k ]  )  ! =  'O': 

k  H — I- .  j  -H-  )  : 

NoBackends  =  str  to  num(  NoBEs  ) : 
k-H-: 

/  *  Initialize  connections  to  backends  ’  / 
net  init (NoBackends)  ; 

/’  send  BACKEND  NO  and  NoBackends  to  backends 
/*  Change  the  message  type  */ 
head. type  =  SetBEno: 


/  send  the  ms  g  to  each  BE  '  / 

for  (  i  =1  :  i  •-  =  NoBac  k  end  s  :  i  =  i  —  1| 

{ 

/’.Put  the  backend  number  into  message  / 

1  en  num  t  o_s  t  r  (  (  i  )  .  NoBEl  eng  t  h  .  &ms  g  [  k  ]  )  : 

msg^k  +  NoBEl eng th  +1 ]  =  ECMs  g ; 

/*  send  the  ms  g  to  the  specified  BE  */ 

h e ad . r e c e i v e r =  GPCLB: 

put  _me  s  s  a  g  e ( ms  g . <fah  e  a  d .  i  )  : 

} 

/*  receive  message  from  a  controller  */ 

/*  task  into  ppcl’s  mailbox  */ 

receive  ( &ms  g [ 0 ]  ,  &h  e  a  d )  ; 

Stops vs  =  F AL  S  E : 
wh ile  (  ! S  t  o  p  S  v  s  ) 

{ 

/  *  send  the  ms  g  to  each  BE  * / 

for  (i=l:  i  <=  NoBackends;  i  =  i  +  1) 

{ 

f*  send  the  msg  to  the  specified  BE  */ 
p  u  t  me  ssage  (msg.&head.i): 

} 


if  (  head. type  =  Stop  ) 

StopSys  —  TRUE ; 

else 

/ *  receive  the  next  me  ssage  *  / 
g  e  t  me  ssage (  fans g [ 0 ]  .  <fah  e  ad )  : 

} / *  end  wh ile  * / 

exit  g  r*a  c  e  f  u  1  1  v  (  )  : 
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/  routine  to  send  message  over  networ'.;  to  a  backend 

put  message!  mp  t  r . h  p  t  r . BEn  um ) 

char  *  mp  t  r  : 

struct  msg_hdr  *hptr; 
i  n  t  BEnum: 

{ 

i  n  t  st  at  . 

ms  glen, 
f  un  c  . 

j  •  k: 

short  i o s b [ 4 ]  : 

char  sndbuf [MSGLEN  +  1], 

intbuf[2]  =  "  \  0 "  ,  /*  null  message  */ 

tmp  s  t  r [ 5 ]  : 

* i f  de  f  EnExF 1 ag 

printf( "Enter  put  _me  ssage\n")  : 

*end  i  f 

hptr  ->  sender  =  PPCLC; 
hptr  ->  receiver  =  GPCLB: 

k=0  ; 

/  *  copy  header  into  me  ssage  to  be  sent  * / 

len  num  to  str(hptr->sender.  3.  tmpstr): 
for  (  j  =0  ;  j  <  3  :  j  -H- ) 

sndbuf [ k  -H-  ]  =  t  mp  s  t  r  [  j  ]  : 

len  n  um  to  st  r (hpt  r->rece iver  .  3.  t  mp  s  t  r  )  : 

for  ( j  =0 :  j  <  3 ;  j  ++ ) 

sndbuf [ k  ++ J  =  t  mp  s  t  r  [  j  ]  ; 

len  n  um  to  str(hptr->type.  3.  t  mp  s  t  r  )  ; 
for  ( j  =0  :  j  <  3:  j  -H-) 

sndbuf  [  k-H-  ]  =  tmp  s  t  r  [  j  ]  ; 


copy  the  message 

j  =0  : 

wh i  1 e  (  ( k  <  MS  GLEN)  && 

(  (  s  ndbu  f  [  k-H-j  =  mp  t  r  [  j  ++]  )  !  =  EOMs  g  )  |  : 


if  (k  >=  MSGLEN) 

printf("’^”  Value  of  MSGLEN  "): 
printf(" should  be  increased  *****  n"): 

ms  g  1  e  n  =  k  : 

/ *  send  the  me  s  S  a  g  e  *  / 

* i f  de  f  pr  flag 

printf(" Cal  ling  qio  write  to  backend  %d  n".  BEnum) 
m  prnt ( sndbuf ,  hptr): 

*  e  '  d  i  f 

func  =  10$  _WR I TEVBLK : 

s  t  a  t  =  s  y  s  $q i ow ( 0 .  b  e  _c  han [ BEnum)  .  func.  iosb.  0.0. 

sndbuf  .  ms  glen.  0.0. 0.0) 

iifdef  pr  flag 

p  r i n  t  f ( "Re  turned  f  r om  qio.  wr i t  e \ n " )  : 

# e nd  i  f 

if  ( ( s  r  a  t  ! =  SSI  NORMAL )  !  j  (  i  o  s  b [ 0 ]  !  =  S  S I  NORMAL ) ) 

{ 

p  r  i  n  t  f  (  "  ’  '  Write  error  be  chan  c^d  .  s  t  a  t  =  ccd  "  )  ; 
p  r i n  t  f ( " ( %x )  ,  i o  s  b [ 0 ] =  %d  ( %x )  *  *  n " .  BEn  um . 

stat.  stat.  iosb|0|.  iosblO]) 

exit  graceful  1 v (  )  : 

} 

/  ’  let  receiver  kn  ow  ms  g  is  there  * / 

* i f  d  e  f  pr  flag 

p  r i n  t  f  (  "Cal  ling  qio.  interrupt  n " )  : 

=  e  n  d  i  f 

func  =  lOI  WR ITEA'BLK  )  I OlM  INTERRUPT: 
s  t  a  t  =  s  v  s  $  q i ow ( 0 .  be  chan[BEn  um  ]  ,  func.  iosb.  0.0. 

intbuf.  I.  0.0. 0.0) 
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—  i f  d  e  f  pr_flag 

print f(" Re  turned  from  qio.  interrupt  n"): 

?end  i  f 

if  ((stat  !=  S  S  $  NORMAL )  ||  (  i  o  s  b  [  0  ]  !=  SS$  NORMA.L  )  ) 

{  ~  ’  ' 

printf("**  Interrupt  error  bechan  %d.  "); 

p  r  i  n  t  f  (  "  s  t  a  t  =  %d  ( %x  )  .  i  o  s  b  [  0  j  =  %d  ( %x  )  *  *  \  n  ”  , 

BEnum,  stat.  stat.  iosb[0],  i o  s  b [ 0 ]  )  : 
exit_gracefullv(); 

} 


# i f  de  f  EnExF lag 

p  r i n  t  f ( " Ex i t  put  _me  s  s  a  g  e \ n "  )  : 


lend  i  f 


/’  Initializes  Decnet  links  to  each  of  the  backends 
ae t  _ i n i t ( NoBEs ) 
i n  t  NoBEs ; 

{ 

i  n  t  s  t  a  t  .  i  ; 
short  i o  s  b  [  4  ]  ; 

char  nodespec[l28].  t  mp  s  t  r [ 5  ]  : 

struct  sd  { 

i  n  t  1  e  ii  : 
char  *  p  t  r  : 

} 

netnam  =  {  5 ,  "NET: "  } . 
neb  =  {  0,  nodespec  }: 

/  i  f  d  e  f  EnExF 1 ag 

p  r i n  t  f ( "Enter  net_init\n"); 

f end  i  f 

for(i=l:  i  <=  NoBEs:  i-H-) 

{ 

(*  assign  a  channel  to  the  net  */ 

stat=  sy s $ a s s i gn (&ne t nam.  &be _c han [ i ] .  0.  0); 

if  ( st at  !=  S S $  NORMAL ) 

{ 

printf("**  Error  in  assign  be  chan  %d  ,  "); 

p  r i n  t  f ( " s  t  a  t  =  %d  ( %x  )  *  *  n " ,  l.stat.stat); 

exit_gracefully(); 

} 

} 

/*  Establish  logocal  link  */ 
for(i=l:  i  <=  NoBEs:  i-H-) 

{ 

/*  build  network  connect  block  */ 
strepy  (nodespec  .  "CSMVni  )  ; 
n  um  to  s  t  r (  i  ,  tmp  str  )  ; 
streat  (nodespec.  t  mp  str): 
streat  (nodespec.  " : :  " 0=GPCLB \ " " ) ; 
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~ i f  de  f  pr_flag 

print  f ( "backend  ^d  nodespec  .  Mtos  "  n".  i.  nodespec): 
iend  i  f 

neb .  1 en=  s t r 1 en ( node s p e c  )  : 

/*  Request  the  connection  * / 

stat=  s  y  s  $  q  i ow (0.  be  _c  h  an [  i ]  ,  10$  ACCESS ,  i o  s  b . 

0 . 070 .  &ncb,  0.0. 0.0); 
if  ((stat  ! =  SS$  NORMAL)  ||  (iosbjo]  !=  SS$_NORMAL)) 
{ 

printf(" *  *  Access  error  be_chan  %d .  s  t  a  t  =  %d  " )  ; 
p  r i n  t  f ( " ( %x  ).’iosb[0j=%d  ( %x )  *  * \ n " ,  i  .  stat. 

stat.  i  o  sb [ 0 ]  .  iosbjO]); 

exit _g raceful ly() ; 

} 

}  /*  end  for  i  */ 

# i f  de  f  EnExF 1 ag 

p  r  i  n  t  f ( " Ex  it  n  e  t  _ i n i t ' n ”  )  : 


/'  routine  to  disconnect  all  network  links 


disc  onne  c  t (  ) 

{ 


i  n  t  s  t  a  t  ,  i  ; 

# i f  de  f  EnExF 1 ag 

printf(" Enter  Disconnect^"): 

*  e  nd  i  f 

for  ( i =1 ;  i  <=  NoBackends;  i-H-) 

{ 

* i f  de  f  pr  flag 

p r i n t f ( "D i s c onne c t i ng  backend  %d\n".  i): 

eendi  f 

stat=  sys$dassgn(be_chan[ i ] ) ; 
if  (  st  at  !  =  S  S  $  NORMAL ) 
printf("**  Dassign  Error  for  backend  %d ,  "): 

printf("stat=  %d  ( %x )  **\n",i.stat,  stat): 

} 

# i f  de  f  EnExF 1 ag 

printf("Exit  Disconnectin''): 

*end  i  f 

}  / *  end  disconnect  * / 


/*  Routine  to  close  network  connections,  then  abort  * / 

exit  graceful  1 y ( ) 

{ 

sleep (DELAY) : 
disconnect () : 
e  x  i  t  (  )  : 


APPENDIX  C  -  THE  MBDS  BACKEND  GET-NET  SOURCE  CODE 


j  *  *  *  *  * 

r 

*  *  *  * 

*  * 

*»***»*****»**)(»»»»:»-.  j 

'/ 

r 

V  A  X  /  V  M 

S 

G  P  C  L  B  ’/ 

r 

V 

j  *  *  *  *  * 

************* 

*  * 

*********************  j 

fine  1 ude 

<s  t  d i o . h> 

r 

Standard  I/O  definition 

"/ 

# i nc 1 ude 

<ssdef .h> 

r 

VMS  return  status  codes 

*/ 

fine  1 ude 

< i ode  f . h> 

r 

VMS  I/O  return  codes 

V 

fine  1 ude 

<ms  gde  f . h> 

r 

DECNET  msg  definitions 

*/ 

fine  1 ude 

<dv i de  f . h> 

r 

VMS  device  definitions 

*/ 

fine  1 ude 

"  c  orxmd  a  t  a  .  d  e  f 

it 

/*  MBDS  corimon  defs 

V 

fine  1 ude 

"ms g . de  f " 

/*  MBDS  msg-type  defs 

V 

# i nc 1 ude 

"f lags .def" 

/ *  MBDS  c  omp  i i e  flags 

V 

f  d  e  f  i  n  e 

MAXBE  16 

/*  max  num  of  backends 

V 

char  ne 

tbuf  [MSGLEN]  ; 

/ *  n  e  two  rk  buffer 

V 

char.  mbxbu f  [MSGLEN ]  ; 

/ *  ma  ilbox  buffer 

V 

char  msg  [MSGLEN]  ; 

/*  MBDS -msg  buffer 

V 

short  net  chan ; 

/*  channel  to  DECNET 

V 

short  mbx  chan; 

/*  channel  to  mailbox 

V 

short  be 

chan  [MAXBE  4- 

i 

] :  /*  chan’s  to  backends 

V 

r 

backend  0  is  controller 

V 

short  be 

dev  [MAXBE  + 

i] 

;  /*  device  num  of  chans 

V 

short  NoBackends; 

/*  the  num  of  backends 

V 

short  next  chan  =  0: 

/*  the  next  avail  chan 

V 

struct  sd 

{ 

i  n  t  1  e  n  : 

char  ’pt  r  : 

}  / *  string 

d  e 

scriptors  for:  */ 

/ *  the  ne  Vwo rk 

device  n  ame  *  / 

n  e  t  n  am  =  {  5 , 

If 

NET : "  }  . 

/ *  the  ma  i 1 b  o  x  n  ame  *  / 

netmbx  -  {  8,  "G  NETMBX"  }; 


struct 


msg  hdr  head; 


ma  in  (  ) 

{ 

int  StopS  y  s :  /  *  svst  em  running  flag  *  / 

9 i f  de  f  EnExF 1 ag 

print f(" Enter  GPCLB  n " ) : 

#end  i  f 

/ *  init  intra-c  omp  u  t  e  r  c  omnu  nication  *  / 

ini tsr  (  GPCLB  ) : 

/*  set  up  to  use  DECNET  */ 

ne  t  _ i n i t ( )  ; 

StopSys  =  FALSE; 
wh ile  (  IStopSys  ) 

{ 

/*  get  a  message  from  the  network  */ 

get  me  s  s  a  g  e ( &ms  g  j  0 ]  ,  &h  e  a  d )  : 

/  *  send  the  me  s  s a g e  *  / 

set  header ( ) ; 

if(  head. type  =  Stop  ) 

{  /‘exit  from  MDBS  */ 

StopSys  =  TRUE : 

head. receiver  =  RECP ; 
send(msg,  &head); 

head. receiver  =  EM ; 
s  e n d  ( ms  g  .  Arhead)  ; 

head .receiver  =  CC : 
send(ms.g  .  &head): 

head.receiver  =  PPCLB: 

.  send(msg.  &head): 

}  j  *  end  if  part  */ 
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M 


S  e  t  BEno  I 


else  iff  head. tv pe  = 

{ 

/ ’  set  n  umb  er  of  backends.  '  / 

/  *  and  this  backend  n  umb  e  r  .  *  / 

/*  GPCL .  itself,  does  NOT  care  * / 
head. receiver  =  RECP ; 
send(msg.  <khead); 

he  ad . r e c e  i  v e r  =  DM: 
send (msg  ,  &head); 

head. receiver  =  CC ; 
send (msg,  &head): 

head . rece i ver '=  PPCLB: 
s  e  n  d  ( ms  g  ,  &h  e  a  d  )  ; 

} 

else  if(  head. type  = 

NewDB  ||  /*  create  new  database  *  / 

head. t  ype  == 

Template  ]|  /*  create  new  template  */ 

head. type  = 

Se 1 ec  tDatabase ) 

/‘assign  database  to  user  */ 

{ 

/*  send  to  ALL  tasks  */ 

head. receiver  =  RECP : 
s  e  n  d  ( ms  g  .  &h  e  a  d  )  ; 

h e ad . r e c e i ve r  =  DM: 
send (msg.  &head): 
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- i f  d  e  f  T i  me  Flag 


#end  i  f 


else  if  ((head. type  >=  MIX  RP  MSGTYPE ) 

(  h  e  a  d  .  t  v  p  e  <=  MAXRPMSGTYPE )  ) 

{ 

head. receiver  =  RECP ; 
s end  (ms g . &he ad )  : 

} 

else  if  ((head. type  >=  MINCCMSGTYPE) 
&£  (head,  type  <=  MAX  CC  MSGTYPE )  ) 

{ 

head. receiver  =  CC ; 
send(msg,&head) ; 

}  ' 

else  if  ((head,  type  >=  MIN  EM  MS GTYPE) 
&&  (head,  type  <=  MAX_EM_MSGTYPE)  ) 

{ 

he  ad . r e c e i v e r  =  EM: 
send  (ms  g . &h  e  ad )  : 

} 

else  if  (head. type  =  GeTimes) 

{ 

head. receiver  =  RECP : 
send (msg ,&head ) : 
head. receiver  =  CC; 
s end (ms g ,&he ad  )  ; 
he  ad  .  r e c e i ve r  =  EM; 
s end (ms  g ,  &he ad )  ; 

}  /*  end  if  (  GeTimes  )  */ 

else 

/*  (  !=  FINISHED  &&  !=  GETIMES  )  */ 

send (msg,  &head); 


}  / *  end  wh i 1 e  * / 


* i f  d e  f  EnExF 1 ag 

printf ("Exit  G_PCLB\n"  )  ; 
#end  i  f 


e  x  i  t  (  )  ; 

}  I  *  end  ma in  * / 
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/ ’  routine  to  get  the  next  me  ssage  f  r  om  the  network 

get  _me  s  s  a  g  e-  ( mp  t  r  .  h  p  t  r  ) 

char  *mp  t  r  : 

struct  msghdr  *hptr: 

{ 

i n  t  sta’  , 

ms  glen, 
f  unc  , 
j  ,  k: 

shor  t  i o s b  [  4  ]  ; 

char  r c vbu f [MSGLEN  +  l]  . 
intbuf [2]  =  "\0" , 
tmp  s  t  r [ 5 ]  ; 

short  ms g  rec  ; 

# i f  de  f  EnExF 1 ag 

printf(" Enter  get  me ssage\n")  ; 

f  end  i  f 

/*  Check  mailbox  for  message  notices  */ 
r eadmbx (mbxbuf ) ; 

/*  Read  the  message  */ 
read  net ( rcvbuf  .  mbxbuf): 

/*  Get  the  header  information  */ 


k=0  : 


/  *  get  sender  *  / 
for  ( j  =0 :  j  <  3:  j  -H-) 

tmp s  t  r  [  j  )  =  rcvbuf  [  k-H- ]  : 

t  mp  s  t  r  [  j  ]  =  ''O': 

hpt  r- >sende  r  =  str_to  num(tmpstr): 

/  4  get  receiver  */ 
for  (  j  =0  :  j  <  3  :  j  -H- ) 

tmp  s  t  r  [  j  ]  =  rcvbuf  [  k-H-  ]  : 
tmp  s  t  r  [  j  ]  *  =  ’\0': 

hptr->receiver  =  str  to  num(tmpstr); 
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/ ’  get  the  type  ’/ 

-for  (  j  =0  :  j  <  3  :  j  -H-) 

t  mp  str[j]  =  rcvbuf[k  -H-  ]  : 
tmp  s  t  r [ j  ]  =  '.0‘: 

hptr->type  =  str_to  n  um(  t  mp  s  t  r )  ; 

# i f  de  f  pr  flag 

mprnt ( rcvbuf .  hptr): 

#end  i  f 


/  *  copy  the  me  s  s  a  g  e  *  / 

j  =0  ; 

while  (  (k  <  MS  GLEN)  &&  (rcvbuf[k]  ! =  ECMs  g )  ) 

mptr(  j-H-]  =  rcvbuf[k-H-]  ; 

mp  t  r [ j  ]  =  rcvbuf[kj;  / *  get  ECMs  g  * / 

if  (k  >=  MSGLEN) 

printf( "*****  Value  of  MSGLEN  "); 
print f(" should  be  increased  ****x\n")\ 

i i f  de  f  EnExF 1 ag 

p  r  i  n  t  f  (  "  Ex  i  t  get  _me  ssage  m”  )  : 

4end  i  f 


}  / r  end  get  me  ssage  *  / 


/'  Routine  to  check  the  nia  i  1  b  o  x  for  me  ssage  notices  '/ 

read  _mb  x ( b  u  f  ) 

char  *  bu  f  : 

{ 


short 

ms  g  rec  ; 

short 

stat; 

short 

i  o  s  b  [  4  ]  ; 

ii fdef 

EnExF 1 ag 

print f(" Enter  read  mbx\n"): 

lend  i  f 

ms  g 

rec  =  FALSE: 

wh  i 

1  e  (  !  ms  g  rec  ) 

{ 

#i fdef 

pr  _f  1  ag 

#end  i  f 

p  r i n  t  f ( "Ca 1  1  i ng 

q i o .  read  ma  i  1  box  n " )  : 

s 

tat=  sys$qiow(0, 

mbx  chan,  IO$  READVBLK.  iosb, 
0,0.  bu  f . “MSGLEN .  0 , 0 , 0 . 0 ) 

# i fdef 

pr_flag 

p r i n t  f ( "Re  turned 

f  r  om  q  i  o  \  n  "  )  ; 

£e nd  i  f 

• 

if  ((stat  ! =  S  S  $  NORMAL )  ||  ( i o  s  b ( 0 ]  !=  SSS  NORMAL ) ) 

{ 

p  r i n  t  f ( " *  *  Ma  ilbox  read  error,  s  t  a  t  =  %d  (%x )  ,  " : 

printf("iosb[0]=  %d  (%x)  *  *  \  n  "  ,  stat.  stat. 

iosb[0]  .  i o  s  b [ 0 ]  )  : 

exit  graceful ly( ) ; 

} 

switch  (  bu  f [ 0 ]  ) 

{ 

case  MSGS  INTMSG: 

f 
«. 

ms  g  r  e  c  = 
break  ; 


TRUE: 


case  MSG*  CONNECT 


1 


*  *  _ll 


} 

f  i  f  d  e  f 
fend i f 


c  on  litre  t  (  bu  f  )  ; 
break  : 

} 

case  MSGS  CONFIRM:  break: 

default:  { 

p  r  i  n  t  f (  "  **  Net  wo  r  k  error, 
p r i n t f ( "mbxbu f [ 0 ] =  %d  (%x )  n' 

bu  f  [  0 ]  .  buf[0 

exit  graceful  1 y ( )  : 

} 

}  /  *  end  switch  *  / 

/ *  end  wh i  1 e  *  / 

EnExF 1 ag 

p  r i n  t  f ( " Ex i t  read  mb  x \ n  "  )  : 


}  /*  end  read  mbx  */ 


CM 


/*  Routine  to  read  a  message  from  a  backend  */ 

read  net  (rcvbuf.  mb  x  b  u  f  ) 

char  *  rcvbuf  ,  *  mb  x  b  u  f  ; 

{ 

short  *un  i  t  , 

BEnum, 
f unc  , 
s  t  a  t  . 
i  o  s  b  [  4  ]  ; 

# i f  de  f  EnExF lag 

p r i n t f ( " En t e r  r e ad_ne t \n " ) ; 

lend  i  f 

uni t=  mb  x  b  u  f ; 

for  ( BEnum  =  0  :  be _de v  [ BEnum]  !  =  un  i  t  [  1  ]  ;  BEnum-H-) 

{ 

if  (BEnum  >=  (next_chan  -  1)  ) 

{ 

printf("***  Cannot  locate  unit  number  to  "); 
printf("read  net  with.  ***\n"); 
p r i n t f (  "  *  *  *  Searched  through  %d  backends,") 
printf("  next_chan=  %d  ***\n",  BEnum,  next  chan) 
ex i t  _g  r  ac  e  f  u  1  1 y  (  )  ; 

} 

} 

# i f  de  f  pr  flag 

p r i n t f ( "Ca 1 1 i ng  qio  read  from  backend  %d\n",  BEnun 

#end  i  f 

func  =  I 0$  READVBLK ; 

stat=  sys$qiow(0,  b e _c h an [ BEnum]  ,  func.  iosb.  0.0, 

rcvbuf.  MSGLEN ,  0,0, 0.0); 

£ i f  de  f  pr_flag 

printf(" Re  turned  from  qio  ,n")  ; 

lend  i  f 


if  (  |  s  t  at  ’  =  S  S  S  NORMAL  ) 


iosblOi  !=  S  S  $  NORMAL  )  ) 


printff"**  Read  error  be  chan  c7d  .  s  t  a  t  =  c"od  ( %x  )  .  "  )  : 

p  r  i  n  t  f  (  "  i  o  s  b  [  0  j  =  Std(^tx)  **  n".  BEnum.  stat. 

star .  iosb;0j,  iosbiO]); 

exit  graceful  1  v  (  )  ; 

} 

*  i  f  de  f  EnExF 1 ag 

p  r  i  n  t  f ( " Ex  i  t  r  e  ad  _n  e  t  \  n  "  )  ; 

-end  i  f 

}  / *  end  read  net  *  / 


cwWir' 


RW 


/ 


Initialize  Dec  net  to  receive  connection  requests 


ne  t  _ i n i t ( ) 

{ 

i  n  t  s  t  a  t  ,  i  : 
short  iosb[4]  : 

^define  NFB$C_DECLNAME  0x15 

char  n  f b  [  5 ]  -  {  NFBSCDECLNAME ,  0,0, 0,0  }; 

struct  sd  { 

i  n  t  1 en ; 
char  *  p  t  r  ; 

} 

objnam  =  {  5 ,  "GPCLB"  } , 
n  f  b  _d  =  {  5  ,  n  f  b  }  ; 

char  tmp  s  t  r  [  5  ]  ; 

# i f  de  f  EnExF 1 ag 

printf( "Enter  net_init\n"); 

#end  i  f 

/  *  create  a  ma i  1 b o x  *  / 

s  t  a  t=sy  s  $  c  r  embx  (  0  ,  &mbx_chan,  MSGLEN,  MSGMAX,  0,  0, 

&ne  tmbx ) 

if  (stat  !=  SS$  NORMAL) 

{ 

printf("**  Error  creating  ma  i 1 b  o  x ,  "  )  ; 

printf("stat=  %d  ( %x )  *  *  \  n " ,  stat,  stat); 

exit  graceful  lv()  ; 

} 

/*  assign  channel  to  the  net  */ 

stat=  s y s $  a s s i gn ( &ne t n am,  &net_chan,  0,  &netmbx); 
if  (stat  ! =  SSI  NORMAL ) 

{ 

printf("**  Error  in  assign  for  netchan,  "); 
printf("stat  =%d  ( %x  )  *  *  \  n "  ,  stat.  stat); 

exi t  graceful  lv(  )  ; 

} 


/‘  declare  a  net  wo  r  k  n  amt  '  / 

stat=  s  y  s  $  q i ow (0.  net  chan.  10$  ACPCONTROL .  i o  s  b . 

0.0.  <knfb_d.  &objnam.  0.0. 0.0); 
if  ((stat  !=  SS$  NORMAL)  ||  ( i o sb [ 0 )  ! =  S S $  NORMAL ) ) 

{ 

printf("**  Error  declaring  net  wo  r  k  n  ame  *  *  \  n  "  )  ; 
exit_gracefully() : 

} 


f i f  de  f  EnExF 1 ag 

p  r i n  t  f ( " Ex i t  net  ini t\n")  ; 


f  e  nd  i  f 


/'  routine  to  accept  a  network  connection  request  ’/ 
connect (buf)  - 


char  *  bu  f  ; 
{ 

short 


offset  , 

s  t  a  t  , 
i  o  s  b  [ 

4]  : 

char 

nodespec[l28]  : 

struct 

s  d  { 

i  n  t 

1  e  n  ; 

char 

} 

neb 

*  p  t  r  ; 

=  {  o. 

nodespec  }; 

1  ong 

dv i un  i  t  [  1  ]  ; 

short 

dv  i  un 

it  1 en [ 1 ] 

• 

/ *  structure  to 

get  unit 

numbers  for  channels  to 

struct 

{ 

short 

1  en  ; 

/*  buffer 

length  *  / 

short 

code; 

/  *  it  em  c 

ode  *  / 

1  ong 

*uni  t  ; 

/*  addr  to  return  unit 

short 

*  un i t 1 en 

;  / *  1 ength 

of  unit  * / 

1  ong 
} 

dv  i  = 

nu  1  ; 

/ *  end  of 

descriptor  *  / 

{  4 ,  DVI $ 

UNIT,  dviunit,  dviunit  1 

#  i  f  de  f 

EnExF 1 ag 

p  r  i  n  t  f  (  " 

En  ter  connectin'1)  ; 

iend  i 

f 

r 

see  if  the 

re  are  any  channels 

available  *  / 

i  f 

(next  chan 

>  MAXBE) 

{ 

pr 

i  n  t  f  (  "  *  * 

Too  many 

connection 

requests  "); 

pr 

i n  t  f ( " a  t  t  emp  ted. 

next  c  han= 

%d  *  * \ n " .  next 

ex 

it  gracefully(): 
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/  Extract  net  wo  rk  connect  block  fr  om  ma  ilbox  buffer  ’ j 


offset  =  buf[4j  +  5:  /’  point  to  neb  length  in  buf  */ 

neb.  1 en  =  buf  [offset j;  /’  put  length  into  our  neb  *  J 
offset-H-;  /*  point  past  neb  length  */ 

for  (  i =0 ;  i  <  neb .  1 en ;  i  -H- )  /*  get  the  neb  *  j 

node  spec  [ i ]  =  buf  [i  +  offset]: 
nodespec [ i ]=  ’ \ 0 ' ; 

fifdef  pr  flag 

p  r  i  n  t  f  (  "  *  *  node  spec=  %s  *  *  \  n  "  .  nodespec); 
printf("**  next_chan=  %d  **\n".  next  chan); 

#end  i  f 

/*  Assign  the  next  channel  to  the  net  */ 
s  t  a  t  =  s y  s  $  a  s  s  i  gn  ( <kn  e  t  n  am,  &be  chan  [  next  chan],  0, 

faie  tmbx )  : 

if  (stat  ! =  S S $  NORMAL ) 

{ 

printf("**  Assign  error  be  chan  %d  ,  " )  ; 

pr  int  f  (  "s  t  at=  %d  ( %x  )  *  *  \  n  "  next  chan, stat,  stat): 

exit_gracefully(); 

} 

/*  accept  the  connection  */ 

stat-  sys$qiow(0.  be _c han [ nex t _c han ] .  IO$_ACCESS. 

iosb,  0.0.0,  &ncb.  0,0, 0,0) : 
if  ( (stat  !  =  S  S  $  _NORMAL )  ]|  ( i o  sb [ 0 ]  !=  SS$_NORMAL)) 

printf("**  Accept  error  be_chan%d,  s t a t =  %d (%x ) , " ) : 
p  r i n  t  f (  "  iosb[0]=  %d(%x)  **\n".  next  ehan,  stat. 

stat.  iosb[0],  i  o  s  b  [  0 ]  )  : 

ex  i  t  _g  r  ac  e  f  u  1  1  y  (  )  ; 

} 


/ ‘  Get  unit  numbers  for  the  channels  ' j 
stat=  svs$getdvi(l.  be_channext  chan]. 

0 . &dv i.  iosb.  0.0,0) 

if  (stat  !=  SSI  NORMAL ) 

{ 

printf("**  Error  getting  channel  number  for  BE  "); 
printf("%d.  stat=  %d  (%x)  **\n", 

next_chan,  stat,  stat) 

exit  graceful ly(); 

.  } 

s  y  s  $wa i t  f  r ( 1 )  : 

if  (  i  o  s  b  [  0  ]  !  =  S  S  $  NORMAL  ) 

{ 

printf("**  Error  getting  channel  n  umb  e  r  for  BE  " )  ; 
print f("  %d ,  iosb[0]=  %d(%x)  **\n",  next  chan. 

i osb [ 0 ] ,  i osb [ 0 ] ) 

exit  graceful  ly(); 

} 

be  dev [next_chan|  =  *dviunit; 

j*  increment  the  available  channel  pointer  */ 
next  chan++; 

# i f  de  f  EnExF lag 

printf("Exit  c onne c t \ n ' ) ; 

?end  i  f 

}  / *  end  c  onne  c  t  *  / 


/ “  Routine  to  disconect  all  of  the  network  links 

disc  onne  c  t (  ) 

{ 

i  n  t  s  t  a  t  ,  i  : 

# i f  de  f  EnExF 1 ag 

printf( "Enter  Disconnectin'')  ; 

#end  i  f 

for  (i=l;  i  <  next_chan:  i-H-) 

{ 

# i f  de  f  pr_flag 

p  r  i  n  t  f  (  "Di  s  c  onne  c  t  i  ng  backend  %d\n",  i): 

fend  i  f 

stat=  sy s $da s s gn ( b e _c h an [ i ]  )  ; 
if  (stat  !=  SS$  NORMAL) 

printf("**  Das  sign  Error  for  backend  %d .  "); 

p  r i n  t  f ( " s  t  a  t  =  %d  (%x)  *  * \ n "  ,  i,  stat,  stat); 

} 

# i f  de  f  EnExF 1 ag 

printf("Exit  D i s c onne c t \ n " )  ; 

#end  i  f 

} 


/*  SETHEADER  assigns  values  to  the  msg  header 
s  e  t  he  ade  r  ( ) 

head. sender  =  G_PCLB; 

/*  set  the  receiver  */ 

head. receiver  =  EM;  /*  the  default 

}  I*  end  set  header  */ 


/ T ’  Close  all  network  connections  before  aborting 
exit  gracefully() 

{ 

s 1 e  ep ( DELAY)  ; 
disconnect  ()  ; 
ex  i  t  (  )  ; 


APPENDIX  D  -  THE  MBDS  BACKEND  PUT-NET  SOURCE  CODE 


j  *  *  * 

******  ********* 

*  * 

*»»**.**  »*,.,********:,  *  j 

'/ 

r 

r 

V  A  X  /  V  M 

S 

P  P  C  L  B  v 

r 

*  / 

i  *  *  * 

*************** 

*  * 

*********************  j 

# i nc 1 ude 

<  s  t  d i o . h> 

r 

Standard  I/O  definition 

§ i nc 1 ude 

<s  sde  f . h> 

r 

VMS  return  status  codes 

*/ 

# i nc 1 ude 

< i od e  f . h> 

r 

VMS  I/O  return  codes 

V 

# i nc 1 ude 

<ms  gde  f . h> 

r 

DECNET  ms  g  definitions 

V 

# i nc 1 ude 

"  c  orand  a  t  a  .  d  e  f 

»» 

/*  MBDS  corrmon  defs 

V 

# i nc 1 ude 

"ms  g  .  de  f  " 

/*  MBDS  msg-type  defs 

*/ 

# i nc 1 ude 

" flags. def" 

/ *  MBDS  c  omp  i  1 e  flags 

*/ 

# i nc 1 ude 

"  b  e  n  o  .  d  c  1  " 

/*  backend  num  declares 

*/ 

#de  f i ne 

MAXBE  16 

/*  max  num  of  backends 

V 

char 

netbuf  [MSGLEN]  ; 

/ *  ne  two  r  k  buffer 

V 

char 

mbxbuf  [MSGLEN]  ; 

/ *  ma  ilbox  buffer 

V 

char 

ms g  [MSGLEN]  ; 

/*  MBDS -ms  g  buffer 

V 

short 

net  chan; 

/*  channel  to  DECNET 

V 

short 

mbx  chan: 

/*  channel  to  mailbox 

*/ 

short 

be  chan  [MAXBE  + 

1];  /*  chan’s  to  backends 

*/ 

r 

backend  0  is  controller 

V 

short 

NoBac  kends  ; 

/*  the  num  of  backends 

V 

short 

next  chan  =  0; 

/ *  the  next  avail  chan 

V 

struct  sd  { 

i  n  t  1  e  n  ; 

char  *ptr; 

}  /  *  string 

d  e 

scriptors  for:  * / 

/  *  the  n e  two  r  k 

device  n  ame  *  / 

n  e  t  n  am  =  {  5 . 

?! 

^NET : "  } , 

/  *  the  ma  i 1 b  o  x  n  ame  *  / 

netmbx  =  {  8,  "PNETMBX"  }; 


struct  ms g  hdr  head; 
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»  / 
/ 


ma  in  (  ) 

{ 

i  n  t  i  : 

int  StopS vs;  /’  loop  flag 

i  n  t  j  .  k  ; 

char  NoBEs [ No BE length  +1 j  : 

char  BENumbe r ( NoBEl en g t h  +1] ; 

# i f  d  e  f  EnExF 1  a  g 
printf(" Enter  p  pci  b\ n " ) ; 

*  end  i  f 

/*  Initialize  intra-computer  communication  */ 
i n i t  s  r  ( P  PCLB)  ; 

/*  set  up  to  use  DECNET  */ 
control ler_net  init(); 

/*  receive  a  message  from  the  controller  */ 
r  e  c  e i v  e ( &ms  g  [  0  ]  .  &h  e  a  d )  ; 

/*  The  first  message  should  be  of  type  SetBEno.  */ 
if  (  head. type  !=  Set  BEn  o  ) 

{ 

printf(  "Error  in  PPCL ,  1st  message  must  ” )  ; 

printf("be  of  type  SetBEno"  ): 

pr int  f (  "  Type  =  %d\n" ,  head . type  )  ; 

m  prnt (&msg [ 0  j  .  &head )  ; 

exit  graceful ly() ; 

} 

/*  get  number  of  backends  */ 

f  o  r (  k=0 , j  =0  ;  (  NoBEs [ j ]  =  ms  g [ k ]  )  ! =  ’ \ 0 ’  ; 

k-H- ,  j++  )  ; 

NoBackends  =  str_to_num(  NoBEs  ): 
k-H-; 

/*  get  backend  n  umb  e  r  * / 

f  o  r (  j  =0  ;  (  BE  Numb  e  r [ j ]  =  ms  g [ k ] )  ! =  ’  \ 0  ’  ; 

k-H- ,  j  -H-  )  ; 

BACKEND  NO  =  str  to  num(  BE  Number  ) ; 
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ba c k e nd _ne t _ i n i t I NoBa c k end s .  BACKEND  NO  |  : 

/  *  main  portion  of  program  ' / 

S  t  opSv  s  =  FALSE : 
wh ile  (  IStopSys  ) 

{ 

/’recv  a  msg  from  a  BE  process  */ 
receive)  (Sans  g  [  0  ]  ,  <Sch  e  a  d  )  ; 

if  (  head. type  =  Stop  ) 

{ 

StopSys  =  TRUE ; 

/*  send  the  msg  over  the  network  */ 

/*  backend  0  is  the  controller  */ 
put  message  (<5ansg[Q],  &head.  0): 

} 

else  if  (  head. type  =  Desclds  ) 

{  /*  send  Desclds  to  other  backends  */ 
he  ad . r e c e  i  v e r  =  EM; 

for  (  i  =  1;  i  <=  NoBackends:  i  =  i  +  1  ) 

{ 

/ *  send  the  Desclds  to  other  backends  */ 
if  (  i  ! —  BACKEND  NO  ) 

{ 

put  mess  age  (<Sonsg[0],  &head.  i): 

} 

}/*  end  for  *  / 

}/*  end  else  if  */ 
else 
{ 

/*  send  all  other  messages  to  controller  */ 

/*  backend  0  is  the  controller  */ 

put  me  ssage(msg,  &head,  0); 

}  f  *  end  else  * / 

} / *  end  wh ile  * / 

* i f  de  f  EnExF 1 ag 

printf("Exit  ppclb.n"); 

*end  i  f 

}  / *  end. ma in  * / 
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/ ■  routine  to  send  a  me  s-age  over  the  network 

put  message (mptr .hptr .BEnum) 

char  *  mp  t  r  : 
struct  msghlr  *hptr; 
i n  t  BEnum: 

{ 

i  n  t  s  t  a  t  . 

ms  glen, 
f  un  c  . 

J  •  k: 

short  i o  sb  [  4  ]  : 

char  sndbuf  [MSGLEN  4-  1 ]  , 

i n  t  b  u  f  [  2 ]  =  " \ 0 " ,  /  *  null  message  *  / 

tmp str  [5]  : 

*  i f  de  f  EnExF 1 ag 

printf(" Enter  put  _me  ssage\n")  : 

?end  i  f 

hptr  ->  sender  =  PPCLC; 

hptr  - >  receiver  =  GPCLB; 

k=0  : 


/  *  copy  header  into  me  ssage  to  be  sent  *  / 

len_num  t o _s t r ( hp t r - > s end e r  ,  3.  tmpstr); 

for  ( j  =0  :  j  <  3;  j  -H-) 

sndbuf[k-H-]  =  tmpstr[j]: 

1 en  num  to  s  t  r (hpt  r- >rece i ver .  3.  tmpstr) 

for  (  j  =0  :  j  <  3:  j  ++) 

s  n  d  b  u  f  (  k  -H-  ]  =  t  mp  s  t  r  [  j  )  ; 

len_num  t o _s t r ( hp t r - > t y pe ,  3,  tmpstr): 

for  ( j  =0 :  j  <  3 ;  j  ++ ) 

sndbuf [ k++]  —  tmp  s  t  r [ j  ]  ; 
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copy  the  me  s  s  a  g  e 


j  =°  : 

wh  i  1  e  (  (  k  <  MSGLEN )  <sc&: 

(  (  s  n  d  b  u  f  [  k  -H-  j  =  mp  t  r  [  j  ++  ]  )  !  =  ECMs  g  )  )  : 


if  (k  >=  MSGLEN) 

pr intf ("* ’ ***  Value  of  MSGLEN  "): 
printf(" should  be  increased  *  *  *  *  *  \  n  "  )  : 

ms  glen  =  k : 


/  *  send  the  me  ssage  *  / 


ft  i  f  de  f  pr_flag 

printf(" Cal  ling  qio  write  to  backend  %d  \ n "  , 

BEnurn)  ; 


mprnt (sndbuf  .  hptr); 

fend  i  f 

func  =  10$  WRITEVBLK; 

stat=  sysSqi ow( 0.  be_chan[ BEnum]  ,  func.'iosb,  0,0, 

sndbuf.  msglen.  0,0, 0,0); 


#ifdef  pr_flag 

pr i n t f ( "Re  turned  from  qio,  writen"): 

fend  i  f 


if  ((stat  !=  SS$_NORMA.L)  |  |  (  iosb  [0]  !  =  SSI  _NORMA.L )  ) 

{ 

printf("**  Write  error  be  chan  %d .  s  t  a  t  =  %d  " )  ; 
p  r i n  t  f ( "  (%x )  .  i o  s  b [ 0 ] =  %d  (%x )  *  *  n " .  BEnum. 

stat.  stat.  iosb[0j.  i o  s  b [ 0 ]  )  ; 

exit  graceful  1 v ( )  : 

} 


/ *  let  receiver  know  ms  g  is  there  */ 
fifdef  prflag 

printf("  Cal  ling  qio.  interruptin'')  : 

# e nd  i  f 

func  =  IO$  WRITEVBLK  |  1 0$M  INTERRUPT: 

stat=  sys$qiow(0.  b e _c h an [ BEnum]  .  func.  iosb,  0.0. 

intbuf.  1.  0.0, 0,0): 
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mill!  W  '^IM^ 


=  i f  de  f  pr  flag 

print f( "Returned  from  qio.  interrupt  n"): 

~  e  nd  i  f 

if  (  ( s  t  a  t  ! =  S  S  $  NORMAL )  |  |  ( i o  s  b [ 0 ]  !  =  S  S  $  NORMAL )  ) 

{ 

printf("**  Interrupt  error  be_chan  %d .  s  t  a  t  =  %d " )  ; 
print f("  (%x).  iosb[Oj=  %d(%x)  **\n",  BEnum, 

stat.  stat.  i o  s  b [ 0 ]  .  i o  s  b [ 0 ]  )  : 

exit _g raceful ly()  : 

} 

f-i  f  de  f  EnExF  1  ag 

printf("Exit  put  message  \n"): 

#end  i  f 

} 
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Routine  to  initialize  De  cnet  to  receive  connections 

control ler_net  init() 

{ 

i  n  t  s  t  a  t  .  i  : 
short  iosb[4] ; 

^define  NFBSCDECLNAME  0x15 

char  n  f  b  [  5  =  {  NFB$C_DECLNAME  ,  0,0, 0,0  }; 

struct  sd  { 

i  n  t  1  e  n  : 
char  *  p  t  r  1 
} 

objnam  =  {  5,  "PPCLB"  }. 
nfbd  =  {  5  ,  n  f  b  }; 

char  tmp  s  t  r  [ 5 ]  ; 

#ifdef  EnExFlag 

pr int  f ( "Enter  control  ler  net  init  n " )  : 

iend  i  f 

/ *  create  a  ma  i  1 b  ox  * / 

stat=svs$cr  emb  x  (  0  ,  &mbx_chan.  MSGLEN  .  MSGMAX. 

0  .  0  .  e  t  mb  x  )  : 

if  (  s  tat  !  =  S  S  $  NORMA.L  ) 

{ 

printf("**  Error  creating  mailbox.  "); 
printf("stat=%d  (%x)  *  * \ n "  ,  stat,  stat): 

exi t  graceful  ly(  )  ; 

} 

/  *  assign  channel  to  the  net  *  / 

stat=  sys$ass  i  gn  line  tnam.  &net  chan.  0.  &netmbx); 
if  (stat  !=  S  S  $  NORMAL ) 

{ 

p  r  i  n  t  f  (  "  *  *  Error  in  assign  for  netchan.  "): 
printf  ("stat  =%d  ( %x. )  *  *  \  n  "  .  stat.  stat): 

exit_gracefully(): 

} 
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,  aeclare  a  net  wo  r  K  n  ante  '  / 

stat=  sys$qi  ow  (  0  .  net  chan.  10$  ACPCONTROL . 

iosb.  0.0.  Arnfb  d.  Atobjnam.  0.0. 0.0) 
if  (  (  s  t  a  t  !  =  S  S  $  NORMAL  )  |  |  (  i  o  s  b  [  0  1  !  =  S  S  $  NORMAL  ) 

{ 

printf("**  Error  declaring  net  wo  r  k  n  ame  ‘  *  n  " 
exit  graceful  1 v (  )  ; 

} 

/ *  check  ma  ilbox  for  connection  requests  */ 
read  mb  x ( mb  x  b  u  f )  : 

/ ’  accept  the  connection  * / 
c  o  n  n  e  c  t  ( mb  x  b  u  f  )  : 


*  i  f  d e  f  EnExF 1 ag 

p  r i n  t  f ( " Ex i  t  controller  net  init  n"): 

=  end  i  f 

} 


ft 


2/2 


AD-A174  179  SOFTWARE  P0RTA8IL ITV ■  A  CASE  STUOV  OF  THE 

MULTI -BACk'ENDED  DATABASE  SVSTEMCU)  NAVAL  POSTGRADUATE 
SCHOOL  MONTEREV  CA  B  D  SILBERMAN  JUN  86 
UNCLASSIFIED  F/G  9/2  NL 


i‘  Routine  to  initialize  Decnet  links  to  backend 


bac kendne t _i n i t (NoBEs .  BEnum) 
i n t  NoBEs ; 


i n t  stat ,  i  : 
shor  t  i osb [ 4 ]  : 

char  node  spec [ 128  ]  ,  tmpstr[5]; 

struct  sd  { 

i nt  1  eh : 
char  *ptr: 

} 

ne  t  n am  =  { 
neb  =  { 

# i f  de  f  EnExF 1 ag 

printf( "Enter  backend _net_init\n") : 

#end  i  f 

f  o  r  (  i  =1  ;  i  <=  NoBEs;  i-H-) 

{ 

if  ( i  ! =  BEnum  ) 

{ 

/*  assign  a  channel  to  the  net  */ 

stat=  sy  s  $  as  s  i  gn  (ke  t  nam,  &be_chan[i],  0. 

if  (stat  !=  SS$_NOEMAL) 

{ 

printf("**  Error  in  assign  be_chan  %d . 
printfj" stat=  %d  ( %x  )  *  * \ n "  .  1  .  stat, 

exit  graceful ly()  : 

} 

}  f*  end  if  i  !=  BEnum  */ 

}  /*  end  for  */ 


5 ,  "  NET : "  } , 

0 .  node  spec  }  ; 


/  "  Establish  logocal  link  '/ 
for  (i=l:  i  <=  NoBEs :  i-H-) 

{ 

if  ( i  ! =  BEnum  )  . 

{ 

/ *  build  network  connect  block  */ 

s  t  rcpy (nodespec ,  "CSMV"); 

num_t o _s t r ( i .  tmpstr); 

strcat  (nodespec,  tmpstr); 

strcat  (nodespec,  " : : \ " 0=GPCLB\ " " ) : 

# i f  de  f  pr_f 1 ag 

printf(" backend  %d  nodespec.  n  )  ; 
pr int f ( " \ "%s \ " \n" ,  i.  nodespec); 

#end  i  f 

neb .  1 en=  s t r 1 en ( node  spec  )  : 

/*  Request  the  connection  */ 

stat=  sys$qiow(0.  be_chan[i],  I 0$  ACCESS. 

i o  s  b ,  0,0,0,  &n  cb,  0,0, 0,0); 

if  ((stat  !=  SS$_NORMA.L)  |  |  (  iosb  [0]  !  =  S  S  $  NORMA.L )  ) 

{ 

printf(M*  Access  error  bechan  %d ,  "); 

printf("stat=  %d  ( %x  )  .  i o  s  b [ 0 ] =  %d  ( %x  )  * \ n " , 

i,  stat.  stat.  iosb[0],  i o s b [ 0 ]  )  ; 
exit  graceful  ly()  : 

} 

}  /*  end  if  i  !=  BEnum  */ 

}  /*  end  for  i  */ 

# i f  de  f  EnExF 1 ag 

p  r i n  t  f ( ” Ex  it  backend  net  init'n")  : 

♦  end  i  f 

} 
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/’  Routine  to  check  the  mailbox  for  message  notices  ’  j 

read_mbx (buf ) 

char  * bu f  : 

{ 

short  connect  rec  ; 
short  stat: 
short  i osb  [  4  ]  ; 

# i f  de  f  EnExF 1 ag 

p  r  i  n  t  f  (  " Enter  re  ad  _mb  x  \  n  "  )  : 

#end  i  f 

connectrec  —  FALSE; 

while  (  !  connect_rec  ) 

{ 

#ifdef  pr_f lag 

p r i n t f ( "Ca 1 1 i ng  qio,  read  mailbox\n"); 

#end  i  f 

s  t  a  t=  sy  s  $q i ow( 0 ,  mbx  chan,  10$  READVBLK, 

i osb ,  0,0.  buf,  MSGLEN,  0,0. 0,0); 

#ifdef  prflag 

pr i nt f ( "Re  turned  from  qio  \n"); 

#end  i  f 

if  ((stat  !=  SS$_NORMAL)|  |  ( iosbfO]  !=  SS$  NORMAL) ) 

{ 

p  r i n  t  f ( " *  *  Ma  ilbox  read  error,  stat=  %d  ( %x )  . " )  ; 
printf("  iosb{0]=%d  (%x)  **\n",  stat.  stat. 

i  o  s  b  [  0  ]  ,  i  o  s  b  [  0  ]  )  ; 

exit_gracefully(); 

} 

switch  ( bu  f [ 0 ]  ) 

{ 

case  MSGS  CONNECT : 

{ 

connect  rec  =  TRUE; 
break: 

} 
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case  MSGS  CONFIRM: 

case  MSGS  INTMSG  break: 

default:  { 

printf("**  Network  error,  "); 
p r i n t f ( "mbxbu f  [  0  ]  =  %d  (%x) 

bu  f [ 0 ]  ,  buf [ 0 ]  ) 

exit_gracefully(): 

} 

}  /  *  end  switch  *  / 

}  /  *  end  wh i 1 e  * / 

# i f de f  EnExF lag 

printf("Exit  r e ad_mbx\n" )  : 

#end  i  f 

}  /*  end  readmbx  */ 
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/'  routine  to  accept  a  network  connection  request  '  / 

c  onne  c  t ( bu  f  ) 

char  *  b  u  f  ; 

{ 

short  i  , 

offset  , 
s  t  a  t  , 
i  o  s  b  [  4  j  ; 

char  node  spec [  1  28 ]  ; 

struct  sd  { 

i n  t  1 en ; 
char  *pt  r ; 

} 

neb  =  {  0,  nodespec  }; 

# i f  de  f  EnExF 1 ag 

printf(" Enter  c onnec t \n" )  ; 

#end  i  f 

/*  Extract  network  connect  block  from  mailbox  buf  */ 

offset  =  buf[4]  +  5:  /*  point  to  neb  length  */ 

ncb.len  =  buf[offset];  /*  put  the  1 en  in  our  neb  */ 
offset-H-;  /*  point  past  neb  length  */ 

for  ( i =0 ;  i  <  ncb.len;  i -H- )  /*  get  the  neb  */ 

nodespec[i]  =  buf  [i  +  offset]: 
nodespec [ i ]=  ’ \ 0 ’ ; 

#ifdef  pr_flag 

printf(” **  nodespec=%s  **\n".  nodespec): 
printf(”  +  :*  next_chan=  %d  **\n".  next  ehan); 

f  end  i  f 
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/’  Assign  controller  channel  to  the  net  / 

stat=  svs$ass  i  gnjirnetnam.  <kbe  chan[0j  .  0.  <knetmbx) 

if  (stat-  !=  S  S  $  NORMAL ) 

{ 

print f("  *  *  Assign  error  be_chan  %d  ,  "); 
p r i n t f ( " s t a t =  %d  (%x)  **\n",  next_chan. 

stat,  stat) 

exit  graceful ly() : 

} 


/*  accept  the  connection  */ 

stat=  sys$qiow(0,  be_chan[0],  IO$_ACCESS, 

iosb,  0,0,0,  &ncb,  0,0. 0,0) 
if  ((stat  !=  SS$_NORMAL) |  |  ( iosb[0)  ! =  S  S  $  _NORMAL ) ) 
{ 

printf("**  Accept  error  be_chan  %d ,  "); 

printf(" stat=  %d  ( %x  )  .  i o  s  b [ 0 ] =  %d  ( %x  )  *  * \ n " , 

next  chan,  stat,  stat,  i  o  s  b [ 0 ]  .  i  o  s  b [ 0 ]  ) 
exit  gracefully(): 

} 

f i f  de  f  EnExF 1 ag 

printf("Exitconnect\n"); 

fend  i  f 

}  /*  end  connect  */ 
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routine  to  disconnect  all  network  links  / 


disc  onnec  t  (  ) 

{ 

i  n  t  s  t  a  t  .  i  ; 

# i f  de  f  EnExF 1 ag 

printf(" Enter  Disconnectin''); 

fend  i  f 

for  (  i  —1  ;  i  <=  NoBackends;  i-H-) 

{ 

# i f  de  f  pr  flag 

p r i n t f ( "Di s c onne c t i ng  backend  %d\n" ,  i); 

# end  i  f 

stat=  sy s Idas s gn ( be _c han [ i ] ) ; 
if  (stat  !=  SSI  NORMAL ) 
printf("**  De assign  Error  for  backend  %d ,  "); 
printf  ("stat=  %d  ( %x )  **\n'',i,stat,  stat); 

} 

# i f  de  f  EnExF 1 ag 

printf("Exit  Di sconnec t \n" ) ; 

fend  i  f 

} 


/*  Routine  to  close  network  connections  then  abort  */ 
exit  gracefully() 

{ 

s 1 e  e  p ( DELAY)  ; 
di  sconnect ( )  : 
ex  i  t  (  )  : 
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